GCM does not prompt for auth on first git call after PATs expire

[whitneyschmidt]

Version

2.5.1+90d5f897f164a8fe07d2aa3bf7db439b0b4e03ea

Operating system

Windows

OS version or distribution

Windows 11

Git hosting provider(s)

Azure DevOps

Other hosting provider

No response

(Azure DevOps only) What format is your remote URL?

https://{org}.visualstudio.com

Can you access the remote repository directly in the browser?

Yes, I can access the repository

Expected behavior

GCM will prompt for auth on the first git.exe call after my PAT expires.

Actual behavior

GCM will not prompt for auth on the first git.exe call after my PAT expires, I am required to make a second git.exe call for GCM to prompt.

Logs

No response

[whitneyschmidt]

My understanding is that this is a GCM limitation due to the way that git.exe handles expired PATs. Are there any plans to implement a fix or improvement for the issue, or recommendations for a workaround?

[whitneyschmidt]

A bit more info:

Is there a workaround for needing to retry?
Yes, you can switch from using PATs to using OAuth by running the following command:

git config --global credential.azreposCredentialType oauth
I've validated that ^ switches to OAuth and eliminates the need to re-auth due to PATs expiring.

Why do PATs require re-trying the git.exe op? git will fail after the PAT has expired, but GCM doesn't have a way to know that it's expired without trying again. tldr; GCM implementation detail.

Will there be a fix that eliminates the need to retry to surface the GCM dialog? Git improvements to credential helper protocol would allow GCM to respond to an initial failure and get a second chance to retry/reauth.

Why does GCM default to PATs instead of OAuth?
PATs were the default before OAuth was supported by GCM. It also used to be the case that some very old versions of Git didn't support long tokens, but this is no longer the case.

What's the different between PATs and OAuth? Are the any drawbacks to switching to OAuth?

The main difference and complication with OAuth is that GCM would now maintain an identity -> resource mapping, whereas before the PAT was directly linked to the URL/resource. There are some edge cases or weird set ups with multiple user accounts or guests in a tenant that can confuse GCM, and haven’t been well tested.

cc @mjcheetham

[rwoll]

I'm facing a similar issue, but am not using PATs.

My first call to git fetch fails with:

fatal: Authentication failed for 'https://<redacted>.visualstudio.com/1ES/_git/<redacted>/'

But the subsequent invocation of git fetch triggers a re-auth flow (auto opens the browser, has me pick an account, completes) then completes the fetch.

This is what I have in my .gitconfig:

[credential]
	helper = 
	helper = /usr/local/share/gcm-core/git-credential-manager
[credential "https://dev.azure.com"]
	useHttpPath = true

$ git --version
git version 2.39.0

$ /usr/local/share/gcm-core/git-credential-manager --version
2.5.0+d34930736e131ad80e5690e5634ced1808aff3e2

macOS 15.1.1 (24B91)

[becm]

@rwoll the Git auth scheme has no way to distinguish auth info for a PAT or a time-limited OAUTH credential.
Both are saved with the same name as user+password.
The user part is ignored on server side, password is mapped to user identification+auth.

There is also no flow to detect/communicate expired credentials.
So it operates as auth required → supply auth → token wrong → delete token.
Then followed by auth required → token missing → token request → supply auth

Using a (non-expiring) PAT would actually avoid the general issue with lifetimes in the OAUTH flow.

[rwoll]

PATs, especially non-expiring, are non-starters and should not be used.

So it operates as auth required → supply auth → token wrong → delete token.

Can this be update to have at least 1 retry/link with:

Then followed by auth required → token missing → token request → supply auth

So the flow would be:

auth required → supply auth → token wrong → delete token → auth required → token missing → token request → supply auth

I think that would solve it…although maybe that buries a more root issue of being explicitly aware of expiry response?

[becm]

@rwoll since there is currently no nice way to identify token expiry, some HostProvider instances try to do discovery and refresh during the get phase of the Git credential helper call.
A *.visualstudio.com domain should suffice to trigger use of GCM's AzureReposHostProvider.
Which (in most cases) will use the PAT auth scheme by default (see also summary in 2nd comment).

The flow from a Git perspective would still look like auth required → (OAuth magic) supply auth → …

But as soon as Git tries and fails with the expired data, it issues an erase.
The credential provider has no way of identifying the origin/reason in the current Git credential protocol.
During the next invocation they are gone, so the provider triggers a request for new data automatically.

Currently no data is stored locally regarding expiration, so the respective providers will have to do their thing.
The flow in regards to new and refresh of tokens may also differ depending on the provider or server.

[rwoll]

Thanks @becm! I will take a look at your pointers and see if I should configure my box differently, or if it makes more sense for me to contribute something upstream.