Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(generic): check local token expiry #1837

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

becm
Copy link

@becm becm commented Feb 13, 2025

Not checking for expired tokens triggers failures on first fetch/push after expiration.
Many Oauth2 implementations use JWT, where expiration time stamp is stored in structured data.
fixes: #1408, #1784

@becm becm changed the title fix(generic): save new refresh_token value fix(generic): refresh of local tokens Feb 14, 2025
@becm
Copy link
Author

becm commented Feb 15, 2025

I'd very much like to have any approach towards identifying local token expiration.
Alternative idea:

  • the username is (for the generic provider, at the moment) basically unused (fixed value).
  • we can change the stored value to OAUTH_USER@<expiration>.

The last approach changing the API for the storage format (#1464) is now stale for almost a year.
Neither suggestions here would need additional code to be touched.

The username approach is likely even waaayyy more compact.
For fully transparent handling of Git credential flow using store, the full username must be retained for the auth_token credential.
Due to limitations of Git using a BasicAuth header, a colon is not a valid separator.

add minimal JWT data class for content decoding and extraction
add decoding support to Base64Url convertor
override GenericHostProvider credential query to check for JWT content
add expiry check to refresh token
@becm becm force-pushed the oauth-refresh-token branch from b467d37 to 482a1ea Compare February 15, 2025 16:37
@becm becm changed the title fix(generic): refresh of local tokens fix(generic): check local token expiry Feb 15, 2025
@becm
Copy link
Author

becm commented Feb 16, 2025

Some major caveat found while trying to prototype a "username@expiration" approach:
API may only return expires_in for the new access_token, not an update refresh_token!

Some storage back ends may also be thrown off by the changing username…

Relative time in protocol additionally indicates this is to be used as a transient element.
Committing that value to permanent storage (after calculating an absolute date) feels like a data flow violation.

For now I'd definitely favor using structured token detection (transparent, backward-compatible, non-intrusive).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GCM OAuth Issue - GCM Erases Expired Token But Does Not Renew - Gitea
1 participant