From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>,
M Hickford via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Eric Sunshine" <sunshine@sunshineco.com>,
Cheetham <mjcheetham@outlook.com>,
Dennington <lessleydennington@gmail.com>,
"Martin Ågren" <martin.agren@gmail.com>,
"Calvin Wan" <calvinwan@google.com>,
"M Hickford" <mirth.hickford@gmail.com>
Subject: Re: [PATCH v2] credential: new attribute oauth_refresh_token
Date: Tue, 02 May 2023 10:19:59 -0600 [thread overview]
Message-ID: <6451382f7aacf_1ba2d29490@chronos.notmuch> (raw)
In-Reply-To: <20230425064758.GD4061254@coredump.intra.peff.net>
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
prev parent reply other threads:[~2023-05-02 16:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 6:46 [PATCH] credential: new attribute oauth_refresh_token M Hickford via GitGitGadget
2023-04-21 9:47 ` [PATCH v2] " M Hickford via GitGitGadget
2023-04-21 16:50 ` Junio C Hamano
2023-04-24 20:11 ` M Hickford
2023-04-25 6:47 ` Jeff King
2023-04-25 19:19 ` M Hickford
2023-05-02 10:25 ` Jeff King
2023-05-02 16:19 ` Felipe Contreras [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6451382f7aacf_1ba2d29490@chronos.notmuch \
--to=felipe.contreras@gmail.com \
--cc=calvinwan@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=lessleydennington@gmail.com \
--cc=martin.agren@gmail.com \
--cc=mirth.hickford@gmail.com \
--cc=mjcheetham@outlook.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).