Windows Credential Manager issues with remote generic OAuth2

[EML-github]

Does anyone have a working setup for Windows Credential Manager, for a generic OAuth2 remote? The setup is identical to my previous question, but with the credentialStore = dpapi line removed from the local .gitconfig.

If the .gitconfig contains an oauthClientSecret, fetch/push work, but the git client produces these error messages:

fatal: Failed to write item to store. [0x6f7]
fatal: The stub received bad data

Without an oauthClientSecret line, nothing works. Git does generate a browser window/tab locally, and I can log into the remote with a username, password, and TOTP. The window then tells me that I'm authenticated and can close the window, but git itself then tells me that authentication failed. Some more data points:

1. Git does produce a new entry in the Windows Credential Manager, named git:https://refresh_token.example.com. The username is OAUTH_USER, which appears to be arbitrary
2. I've tried manually changing the username and password in the Credential Manager, but nothing seems to work. I'm guessing that the password should be a session token of some sort, but the session token returned from the remote Keycloak doesn't work as a password
3. 'Git for Windows' pops up user and password entry boxes. Again, I have no idea what should go in these, and nothing I've tried works.

Have I missed something in the docs? Is anyone else doing this, or are you all on Github/etc??

[EML-github]

I forgot to say - with a Linux client, using git-credential-oauth, everything works as expected with this remote, so the Apache setup with mod_oauth2 and Keycloak is known to work. The .gitconfig is:

[credential "https://example.com"]
  helper            = cache --timeout 7200
  helper            = "oauth -verbose"
  oauthClientId     = openid-cli
  oauthScopes       = "openid email"
  oauthAuthURL      = ...as before
  oauthTokenURL     = ...as before
  oauthRedirectUri  = http://127.0.0.1
  oauthClientSecret = ...as before

[user]
  name  = ...
  email = ...

[becm]

Normal OAuth flow: request grant stuff → refresh_token → access_token

An access_token (the thing Git can work with) has a short lifetime and a new one must be requested after a short while.
While refresh_token (might) also expire, they can (optionally) be rotated on each access_token request.

The following is based on the observed effects and my pure speculation on the cause…

While the initial access_token is valid, Git operations can happen normally.
After it expires, a valid refresh_token must be used to request a new one.

There is currently a bug in GCM (#1838) not saving an inline refresh_token update for access_token response.
So in case your server enforces strict Refresh token rotation this invalidates the OAuth data on the next request.

You might have gotten away with deleting (aka. changing the value of) the oauthClientSecret after the initial setup.
But it seems if there is any need to get a new initial refresh_token, the mismatch is detected and the client is rejected.

So in summary:

• do not change/touch the oauthClientSecret, the refresh_token may also expire by itself at some point
• make sure all clients are distinctly identifiable by the server, so their token rotations do not clash
• hope the fix for refresh_token rotation will ship in a timely manner.

With fixes for token related issues (#1838 and #1837), the OAuth flow with our local Forgejo instance works flawlessly. ☺