Personal Access Token (classic) still working after being deleted

[jmevel]

Select Topic Area

Bug

Body

My personal PC recently got compromised by a malware so I decided to delete ALL my Personal Access Token from the Developer Settings page.

Today, on my work laptop (running Windows) I noticed I'm still able to pull/push on private Github repositories from my personal account.
My PAT is stored in the Windows Credentials Manager and when I delete it and try to git pull it shows me an authentication popup as expected (I then restored a backup I previously made and it's working again).

I tried to extract the password value but my company deleted the PowerShell module allowing us to do that (for obvious security reasons) so I was unable to see what PAT is used.

This is very worrying that deleted PAT aren't automatically revoked as one would expect.
Anyone encountered the same issue?

Note: I never use ssh to clone repos, always HTTPS with a Personal Access Token (classic) with all the repo scopes

Thanks for your answers

EDIT: I just thought of the possibility that I used sign in with your browser or sign in with code features instead of using a classic PAT.
That may explain it, but in that case how would one revoke this kind of authentication from Github?
In the Sessions settings I'm able to see a list of Web Sessions but none of them have a button to revoke them (I can only the the Details)

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams.
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences.
• GitHub staff may reach out for further clarification or insight.
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[hpsin]

You're on the right track with the app based sign in. You should be able to see the apps you've authorized in your settings - go to https://github.com/settings/applications and look through the authorized oauth apps tab - you should see the app listed there. Hit revoke and it'll kill the token.

[jmevel]

Thank you !!!
At first I was a bit confused by this answer but after a bit of digging and experimenting I got the whole picture.

Here is the summary for anyone passing here:

Git Credential Manager

• On Windows, Git Credential Manager is installed by default when you install Git for Windows.
• When you try to clone a private Github repository, it will automatically trigger Git Credential Manager and after the authentication process is completed you can see this 3rd party application listed under Settings -> Applications (as mentioned by Hirsch)
• @hpsin correct me if I'm wrong for this bullet point but as I understand it, one can only revoke the entire Git Credential Manager application from accessing the Github account. If we have multiple machines all using Git Credential Manager, it's currently not possible to revoke only one of them (and what if after revoking it we allow this application again? Does that give back access to all machines that were previously using it?)
• On Windows, the credentials can be viewed in the Windows Credential Manager with the network address git:https://github.com
• You can list saved credentials by running the command git credential-manager github list
• I haven't found yet how to easily access the password/secret (besides using some PowerShell modules)
• I don't exactly know what rights this authentication flow gives us but at least it gives read/write rights on ALL your repositories since there's no way to specify a single or a list of repositories

Personal Access Token

• In order to really use a PAT, the Github CLI must be installed. When you run gh auth login you have the option to Paste an authentication token
• Once this process is completed, on Windows, the credentials can be viewed in the Windows Credential Manager with the network addresses gh:github.com and gh:github.com:<USERNAME>
• You can verify the account currently used by running gh auth status
• You can even display the PAT with the command gh auth token
• Unlike the Git Credential Manager, a PAT can be created and revoked easily for a single machine
• Unlike the Git Credential Manager, a Fine-grained PAT can be "crafted" to only have access to a single (or a list of) repository

Conclusion

If you carefully read all the bullet points above you probably noticed a PAT can be easily retrieved with a simple command.
Although, I haven't found yet a way to do the same thing when the authentication was performed through Git Credential Manager (I'm curious to know the answer if you have it @hpsin) it does NOT mean it's not possible.
At the end of the day, the git command you're running using your regular user doesn't ask you admin rights every single time to access the credentials stored at the OS level. It NEEDS to be able to retrieve a token in order to send authenticated requests to the Github server so it needs to be able to retrieve it with the same rights as the user executing the command.

Side notes

If you're on Linux, chances are your credentials are stored in GNOME Keyring or KWallet (managed by the KWalletManager GUI) depending of your Desktop Environment

[jmevel]

I have answered one of my questions: When revoking an application and re-authorizing it again, machines which were using this application don't have access anymore. You must perform the authorization flow from the beginning again.

What I did to prove this:

1. gh auth login and chose Login with a web browser
2. Backed up my Windows credentials (rundll32.exe keymgr.dll,KRShowKeyMgr)
3. Revoked the Github CLI application from https://github.com/settings/applications
4. Made sure I didn't have access anymore by running a simple git pull
5. Manually deleted my Github credentials (almost the same as running gh auth logout I believe)
6. Performed the authorization flow again: gh auth login and chose Login with a web browser (that gave me a new token)
7. Made sure I recovered access by running a git pull
8. Restored my Windows credentials backed up at step Feature Request: Select a column when adding an issue to a project #2 (thus overwriting the new token I just got and restoring the old one)
9. Executed a git pull again --> Access denied, invalid token

Conclusion: old tokens linked to an application are made PERMANENTLY invalid once the application is revoked.

This is OAuth2/OIDC 101 but I feel better I managed to verify it (especially considering my initial issue that one of my computers got compromised by a malware)