OAuth2 support in git?

Can I use native git as client to contact a git server which does
authentication with OAuth2 Client Credentials Grant [1]?

Background: We are running gerrit based git servers [2] in a cloud
environment. That environment supports OAuth2 authorization for the
apps running in the cloud. The idea is that clients (e.g. jenkins
jobs) talking git over http with such git servers should be able to
use OAuth2 tokens to authenticate clone/fetch requests. We would have
to adapt gerrit source code for token handling/validation but I am
asking here about the client side.

I know that other git server environments like github support that on
client side by allowing tokens to be used as usernames in a BASIC
authentication flow. We could do the same but I am asking whether
there is also a way to transport tokens in a standard conform
"Authorization: Bearer ..." Header field.

[1] https://tools.ietf.org/html/rfc6749#section-4.4
[2] https://www.gerritcodereview.com/

On Thu, Jun 14, 2018 at 10:09:39AM +0200, Christian Halstrick wrote:

Can I use native git as client to contact a git server which does
authentication with OAuth2 Client Credentials Grant [1]?

Background: We are running gerrit based git servers [2] in a cloud
environment. That environment supports OAuth2 authorization for the
apps running in the cloud. The idea is that clients (e.g. jenkins
jobs) talking git over http with such git servers should be able to
use OAuth2 tokens to authenticate clone/fetch requests. We would have
to adapt gerrit source code for token handling/validation but I am
asking here about the client side.

I know that other git server environments like github support that on
client side by allowing tokens to be used as usernames in a BASIC
authentication flow. We could do the same but I am asking whether
there is also a way to transport tokens in a standard conform
"Authorization: Bearer ..." Header field.

There isn't any support for Bearer authentication in Git.  For HTTP, we
use libcurl, which doesn't provide this natively.  While it could in
theory be added, it would require some reworking of the auth code.

You are, of course, welcome to send a patch.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:

quoted

I know that other git server environments like github support that on
client side by allowing tokens to be used as usernames in a BASIC
authentication flow. We could do the same but I am asking whether
there is also a way to transport tokens in a standard conform
"Authorization: Bearer ..." Header field.

There isn't any support for Bearer authentication in Git.  For HTTP, we
use libcurl, which doesn't provide this natively.  While it could in
theory be added, it would require some reworking of the auth code.

You are, of course, welcome to send a patch.

If it's just a custom Authorization header, we should be able to support
it with existing curl versions without _too_ much effort.

I think there are probably two possible directions:

 1. add a special "bearer" command line option, etc, as a string

 2. add a boolean option to send the existing "password" field as a
    "bearer" header

I suspect (2) would fit in with the existing code better, as the special
case would mostly be limited to the manner in which we feed the
credential to curl. And you could probably just set a config option for
"this url's auth will be oauth2", and use the existing mechanisms for
providing the password.

We'd maybe also want to allow credential helpers to say "by the way,
this password should be treated as a bearer token", for cases where you
might sometimes use oauth2 and sometimes a real password.

-Peff

On June 14, 2018 11:15 AM, Jeff King wrote:

On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:

quoted

quoted

I know that other git server environments like github support that
on client side by allowing tokens to be used as usernames in a BASIC
authentication flow. We could do the same but I am asking whether
there is also a way to transport tokens in a standard conform
"Authorization: Bearer ..." Header field.

There isn't any support for Bearer authentication in Git.  For HTTP,
we use libcurl, which doesn't provide this natively.  While it could
in theory be added, it would require some reworking of the auth code.

You are, of course, welcome to send a patch.

If it's just a custom Authorization header, we should be able to support it
with existing curl versions without _too_ much effort.

I think there are probably two possible directions:

 1. add a special "bearer" command line option, etc, as a string

 2. add a boolean option to send the existing "password" field as a
    "bearer" header

I suspect (2) would fit in with the existing code better, as the special case
would mostly be limited to the manner in which we feed the credential to
curl. And you could probably just set a config option for "this url's auth will
be oauth2", and use the existing mechanisms for providing the password.

We'd maybe also want to allow credential helpers to say "by the way, this
password should be treated as a bearer token", for cases where you might
sometimes use oauth2 and sometimes a real password.

Be aware that there are 4 (ish) flavours of OAuth2 the last time I checked. It is important to know which one (or all) to implement. The embedded form is probably the easiest to comprehend - and the least implemented from my research. More common OAuth2 instances use a third-man website to hold session keys and authorization. That may be problematic for a whole bunch of us who do not play in that world.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(211288444200000000)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

On Thu, Jun 14, 2018 at 04:46:10PM -0400, Randall S. Becker wrote:

quoted

I suspect (2) would fit in with the existing code better, as the special case
would mostly be limited to the manner in which we feed the credential to
curl. And you could probably just set a config option for "this url's auth will
be oauth2", and use the existing mechanisms for providing the password.

We'd maybe also want to allow credential helpers to say "by the way, this
password should be treated as a bearer token", for cases where you might
sometimes use oauth2 and sometimes a real password.

Be aware that there are 4 (ish) flavours of OAuth2 the last time I
checked. It is important to know which one (or all) to implement. The
embedded form is probably the easiest to comprehend - and the least
implemented from my research. More common OAuth2 instances use a
third-man website to hold session keys and authorization. That may be
problematic for a whole bunch of us who do not play in that world.

I think Git's usage would be limited to "how do I present this token for
my requests". I don't think we'd ever recognize an oauth redirect and
try to fulfill it ourselves.  We'd rely on getting a 401 and punting all
those bits to a credential helper to do the heavy lifting.

I say that not knowing much about oauth2, of course, so maybe there
would be complications with that approach (I do know there are multiple
ways you can present a token, but we'd support whichever ones people are
interested in enough to show up and provide a patch for).

-Peff

On Thu, Jun 14, 2018 at 11:15:07AM -0400, Jeff King wrote:

On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:

quoted

There isn't any support for Bearer authentication in Git.  For HTTP, we
use libcurl, which doesn't provide this natively.  While it could in
theory be added, it would require some reworking of the auth code.

You are, of course, welcome to send a patch.

If it's just a custom Authorization header, we should be able to support
it with existing curl versions without _too_ much effort.

It shouldn't be too difficult, but we have some fallback among various
authentication types that would need reworking.

I think there are probably two possible directions:

 1. add a special "bearer" command line option, etc, as a string

 2. add a boolean option to send the existing "password" field as a
    "bearer" header

I suspect (2) would fit in with the existing code better, as the special
case would mostly be limited to the manner in which we feed the
credential to curl. And you could probably just set a config option for
"this url's auth will be oauth2", and use the existing mechanisms for
providing the password.

I agree option (2) would be better.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Hi Peff,

On Thu, 14 Jun 2018, Jeff King wrote:

On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:

quoted

quoted

I know that other git server environments like github support that on
client side by allowing tokens to be used as usernames in a BASIC
authentication flow. We could do the same but I am asking whether
there is also a way to transport tokens in a standard conform
"Authorization: Bearer ..." Header field.

There isn't any support for Bearer authentication in Git.  For HTTP, we
use libcurl, which doesn't provide this natively.  While it could in
theory be added, it would require some reworking of the auth code.

You are, of course, welcome to send a patch.

If it's just a custom Authorization header, we should be able to support
it with existing curl versions without _too_ much effort.

Indeed. Because it is already implemented:

	git -c http.extraheader="Authorization: Bearer ..." ...

To make this a *little* safer, you can use http.<URL>.extraheader.

Ciao,
Dscho

On Sun, Jun 17, 2018 at 01:37:24PM +0200, Johannes Schindelin wrote:

quoted

If it's just a custom Authorization header, we should be able to support
it with existing curl versions without _too_ much effort.

Indeed. Because it is already implemented:

	git -c http.extraheader="Authorization: Bearer ..." ...

To make this a *little* safer, you can use http.<URL>.extraheader.

Yeah, that will work for some cases. A few places it might not:

 - some people may want to provide this only in response to a 401

 - some tokens may need to be refreshed, which would require interacting
   with a credential helper to do the rest of the oauth conversation

 - there's no good way to hide your token in secure storage (versus
   sticking it on the command-line or in a config file).

-Peff