GCM OAuth Issue - GCM Erases Expired Token But Does Not Renew - Gitea #1408
Assignees
Labels
auth:oauth
Specific to OAuth2 authentication
auth-issue
An issue authenticating to a host
bug
A bug in Git Credential Manager
Comments
|
Okay so I went to my For what it is worth, I followed https://github.com/hickford/git-credential-oauth to set up my |
Messages prepended with It may be that the stored token had expired, and needed to be refreshed. Reattempting authentication should fix this.
Looking at the screenshot of the Windows Credential Manager, I can see that there are three entries. It may be the case that some misconfiguration has occurred and a stale token has been stored. Please could you share your Git configuration? git config --list --show-scopeAlso are you using or have you installed |
That is also what I thought at first, but I can replicate this every time after 1-2 hours (still trying to determine when it occurs so let's use that timeframe loosely). My Git Configuration is below as requested
I did copy the
I'm not very experience with OAuth applications so assume I am as novice as they come. It might be the simplest issue on my end. Below you will find my Gitea OAuth application
|
I see that you have both GCM and git-credential-oauth configured. I wonder if there may be some interop issues between the two. Please can you try deleting all of the related credentials from the Windows Credential Manager, enabling both I'd like to check what interaction is happening, and which helper is responsible for creating the 3 credentials shown in your screenshot. GCM should only be creating 2. |
|
I'll go ahead and do that - in fact, I'm hitting the 2 hour window since my last commit so I want to see if removing EDIT: Removing |
|
Okay here's what I did, I removed
I checked Credential Manager and only see 2 credentials being stored as you said it should be happening.
Maybe I did not need Like I said, brand spanking new to this OAuth stuff :) |
|
I decided to give it a try again, roughly an hour and some after posting my last comment. First time I did For some reason when I ran Reading those logs I see two or three lines that caught my eye which I guess matches the behavior I saw when it first failed and I noticed a missing credential. I can't find anything in Gitea's documentation in regards to these two values but these are the other lines that caught my attention. |
|
I was able to replicate the issue - it looks like it deletes the token but did not attempt to refresh it? |
|
@mjcheetham I can replicate this issue consistently where the credentials gets erased and it re-adds new credentials on |
aotongarcia
changed the title
remote: Verify
|
I come bearing more logs! I haven't performed a There are about 365 lines but I'll point out the important ones - if you want me to use an external paste service next time just let me know - happy to accommodate since this looks like a bunch of word vomit in a GitHub comment. Line 30 and 39 we see the credential being erased - this was roughly 40 minutes since my last Line 56 we see GCM not finding the credentials and creating a new one, this was me runing Lines 309-310 we see the credentials being erased roughly 3 hours after my last Line 326 we see GCM doing what I'd expect it to do and create the new credential without my Below are the full logs: |
|
@aotongarcia - thanks so much for including the full logs, that's super helpful! I believe what you're seeing is an expected flow. These docs show that Gitea OAuth access tokens expire after 1 hour. From what I observed in your logs, you were able to authenticate successfully for ~1 hour between erases, so this seems to make sense. Per the OAuth RFC, longer-lived refresh tokens should be used to "refresh" expired access tokens. According to the docs linked above, Gitea refresh tokens last for 730 hours. From what I can tell, it seems like GCM is using your refresh token to obtain a new access token after old ones are erased. New tokens last an hour and then the process resumes when you next authenticate. My hunch here is that there was some weirdness going on with GCM/
Also, can you verify that you're not being prompted by GCM when the erases occur? The new access tokens should be generated by GCM via the refresh token with no user interaction. |
|
@ldennington thanks for following up! I have removed The problem I am seeing now is that GCM makes no attempt to fetch a new access token when it erases the expired one. Currently this is whats happening (from what I understand):
I am not being prompted when it fetches the new token, and what I mean by this is that a new window does not open on my browser. |
ghost
mentioned this issue
|
I think I'm hitting this. Git commands frequently yield "Authentication failed". Deleting two entries from Windows Credential Manager (ones is "refresh_token") works around it, opening the browser page again. I'm logging into self hosted Gitea using "Log in with GitHub". |
|
Running clone twice in a row also seems to work in my case. I guess it refreshes the token. Confusing for users, though. |
Same here, I have authenticated once in Gitea, but after a while the token expires and the command fails.
|
|
Have the same issue. Does anyone have a solution yet? |
|
I am now regularly hitting this as well. unsure if it is gitea side, git on gitea side or client side... |
|
This seems to be on the GCM side. I can delete the access token from Windows Credential Manager, run a push or pull, and GCM will use the refresh token to get a new access token, and it works fine. After that, the new access token is also stored in Windows Credential Manager, and it works until it is expired. However, if the access token in Windows Credential Manager is expired (or invalid... ie. edit it manually and just put "zzz" in the password field) it will cause a push/pull to fail. Rather than refreshing the invalid/expired access token, GCM seems to delete it and give up, which is why it works fine the second time. There is also an issue for this in the Gitea repo: |
|
Isn't this the same issue as #1705? |
|
I would assume it doesn't help for Gitea, but there's something going on here, in the sense there's at least one more case of very similar symptoms. I'm also curious is this has been always an issue with Gitea or started at some point, given the description in #1705, it should have never worked properly? |
I don't think GCM support for Gitea was added until GCM 2.4.1, and that's why it's only showing up now. EDIT: Based on my old Windows 10 machine's configuration, I was using "manager-core" (version 2.0.394) before, and now I am using "manager" (version 2.5.1) on my Windows 11 machine. I also tried manager-core 2.6.0, which has the same behavior. EDIT2: The azreposCredentialType (which looks specific to Azure) does not seem to have any effect on Gitea (which seems to already be using OAuth), but it does sound like the same behavior, and probably the same root cause. I thought it might be something in the GetOAuthAccessToken method, but I suspect that it is somewhere higher up, because according to the Windows Credential Manager, my refresh token hasn't been modified in almost a month, even though I've directly cleared out the access token and it has been restored. Shouldn't the refresh token get rotated each time if that's being used to get a new access token? |
There used to be a different |
@jonathanduke I think I've been experiencing this same behavior. Every now and then (when the first @mjcheetham There have been no updates from the GCM team on this issue for 13 months. Is there any prospect of a fix being implemented? |
|
I also still face this issue. Quite annoying tbh.. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
2.3.2
Operating system
Windows
OS version or distribution
Windows 11 Enterprise 22H2
Git hosting provider(s)
Other - please describe below
Other hosting provider
Self-hosted Gitea
(Azure DevOps only) What format is your remote URL?
None
Can you access the remote repository directly in the browser?
Yes, I can access the repository
Expected behavior
When I run
git pushafter committing my changes I'd expect the behavior to be as folows:Actual behavior
When running
git pushafter a certain amount of time (I want to say 1-2 hours) I get the following errorThe only way I can get around this is removing all these entries from Windows Credential Manager. The current authentication in the internal Gitea server is using Azure AD for whatever that might be worth.
Logs
The text was updated successfully, but these errors were encountered: