fix(generic): check local token expiry

[becm]

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]

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.

[becm]

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).

[lostmsu]

@mjcheetham @mpysson can you please take a look at this change? It's already been iterated upon.

[lostmsu]

@mjcheetham @mpysson there've been no changes in this project for 5 months. Can I co-maintain it? Not sure if I can do it long term but I promise to go through the currently open pull requests at the very least. Better than nothing.

[itsjustnickdev]

any updates on this push?

[dscho]

any updates on this push?

@itsjustnickdev cautiously: yes. I opened https://github.com/git-ecosystem/git-credential-manager/issues/2059.

However, during the extended time of ownership limbo, Git Credential Manager's release process has withered to the point where no releases can be made as of time of writing (notarizing, for example, is broken, yet it is required for Git Credential Manager to work on macOS).

Therefore, the primary concern right now is to get that release process into a healthy shape.

If you want to look into #2059 in the meantime, that would be really cool, of course!

[becm]

@mjcheetham replaced handling of JWT with a generic StructuredToken placeholder.

This should make expanding support (or replace implementation) fairly easily later on. Kept the minimalist JWT extraction approach (fancy 3-liner plus boilerplate) for now.