Jeff King wrote:

On Fri, Apr 21, 2023 at 09:47:59AM +0000, M Hickford via GitGitGadget wrote:

quoted

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