git-ecosystem
Credential protocol enhancement: OAuth token expiration and refresh tokens
Starting in Git 2.40, the protocol learned a few new keys including around storing and retrieving an OAuth token's expiration date. This will be helpful to support such that tokens stored in credential stores can be used or discarded without an extra network call to determine if they are still within the validity period.
Likewise, the protocol from v2.41 now includes an optional OAuth refresh token key that allows helpers to more easily communicate both an access and refresh token as part of a get + store/erase request and response pair. Today, host providers have had to preemptively store the refresh token manually, in a separate credential store entry, even if the incorrect user account was selected.
Author: @mjcheetham
It's probably worth nothing the lack of support here does lead to problems with Forgjeo instances: https://codeberg.org/forgejo/forgejo/issues/2809
@crablab just making the data available will not help without further code. To have notable effect, using a multi-step auth schema (#2057) would be needed (and triggered) on expired items.
Expiry check (#268) with internal refresh (#1837) is a more ~primitive~contained solution to this issue. ☺
@dscho putting the refresh_token on the wire may have security drawbacks:
- any process can (technically) ask for an
access_token - it gets the (much more critical)
refresh_token"for free" - in many scenarios, this is enough to maliciously invalidate the OAuth client registration.
If I'd have to choose; better to (proactively) refresh the requested access_token internally on detected expiry.
(And maybe even think of ways to better secure the refresh_token as a private GCM secret).
