git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: OAuth2 support in git?

From
Randall S. Becker <rsbecker@nexbridge.com>
Date
Jun 14, 2018, 20:46 UTC
Message-ID
<003c01d40420$bd522990$37f67cb0$@nexbridge.com>
In-Reply-To
<20180614151507.GA6933@sigill.intra.peff.net>
On June 14, 2018 11:15 AM, Jeff King wrote:
Show 32 quoted lines
> On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:
> 
> > > 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.
Previous: Jeff KingNext: Jeff King
Message 4 of 12 in “OAuth2 support in git?”
  1. Christian HalstrickJun 14, 2018
  2. brian m. carlsonJun 14, 2018
  3. Jeff KingJun 14, 2018
  4. Randall S. BeckerJun 14, 2018
  5. Jeff KingJun 14, 2018
  6. brian m. carlsonJun 14, 2018
  7. Johannes SchindelinJun 17, 2018
  8. Jeff KingJun 18, 2018
  9. Junio C HamanoJun 18, 2018
  10. Jeff KingJun 18, 2018
  11. Christian HalstrickJun 19, 2018
  12. Jeff KingJun 19, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.