Re: [PATCH v2] credential: new attribute oauth_refresh_token

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King wrote:
> On Fri, Apr 21, 2023 at 09:47:59AM +0000, M Hickford via GitGitGadget wrote:
> 
> > Git authentication with OAuth access token is supported by every popular
> > Git host including GitHub, GitLab and BitBucket [1][2][3]. Credential
> > helpers Git Credential Manager (GCM) and git-credential-oauth generate
> > OAuth credentials [4][5]. Following RFC 6749, the application prints a
> > link for the user to authorize access in browser. A loopback redirect
> > communicates the response including access token to the application.
> > 
> > For security, RFC 6749 recommends that OAuth response also includes
> > expiry date and refresh token [6]. After expiry, applications can use
> > the refresh token to generate a new access token without user
> > reauthorization in browser. GitLab and BitBucket set the expiry at two
> > hours [2][3]. (GitHub doesn't populate expiry or refresh token.)
> > 
> > However the Git credential protocol has no attribute to store the OAuth
> > refresh token (unrecognised attributes are silently discarded). This
> > means that the user has to regularly reauthorize the helper in browser.
> > On a browserless system, this is particularly intrusive, requiring a
> > second device.
> > 
> > Introduce a new attribute oauth_refresh_token. This is especially
> > useful when a storage helper and a read-only OAuth helper are configured
> > together. Recall that `credential fill` calls each helper until it has a
> > non-expired password.
> > 
> > ```
> > [credential]
> > 	helper = storage  # eg. cache or osxkeychain
> > 	helper = oauth
> > ```
> 
> OK. I don't have much knowledge of OAuth, but taking the notion of "this
> is a useful thing for oauth clients to store" as a given, the
> implementation seems reasonable.

I don't think this is specific to OAuth, I've seen different authorization
methods use something like that.

In general you just need two variables: the refresh token, and the expiration
time of the refresh token. The logic is very simple: if the refresh token has
expired, you ask for a new one. This way you don't have to go through the
authorization process again.

-- 
Felipe Contreras



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux