What an OAuth authorization actually is
When you click “Authorize” on a third-party app, GitHub records a grant: the app can now act on your behalf within the permissions you approved. That grant is not your browser session, not an SSH key, and not an installed GitHub App with its own installation settings. Each of these is revoked or removed in a different place, so the first step is identifying which kind of access you are actually looking at.
| What you see | What it is | Where it is managed |
|---|---|---|
| A third-party app listed with scopes you approved | OAuth authorization | Settings → Applications → Authorized OAuth Apps |
| A key pair you added for Git over SSH | SSH key | Settings → SSH and GPG keys |
| You are signed in in this browser | Login session | Signing out, or the sessions page |
| An app installed on a repository or organization | GitHub App installation | The app’s or organization’s installation settings |
If the entry you are looking at is not an OAuth authorization, revoking it from the OAuth list will not address it.
Why review before you revoke
An old authorization may still be doing something you rely on, such as a deployment tool, an editor plugin or a CI integration. Revoking it cuts off that app’s access through the grant, which is the point, but it can also break a workflow that still depends on it. Review the app name, the permissions listed, and when you last used it before acting.
GitHub recommends reviewing authorized applications, including applications with access to private repositories. Source
If you do not recognize the app, or the access it holds is broader than the task it performs, that is the case for revoking. If you recognize it and still use it, consider whether the current scopes are still appropriate before deciding.
Before and after checklist
Use this as a short record so you can tell what changed and undo a mistake if needed.
Before revoking
- Note the app name and the permissions shown for it, so you can recognize the same entry later.
- Check whether anything you currently use depends on that app: a build, a deploy, an editor login, a scheduled job.
- Confirm you are looking at Authorized OAuth Apps and not SSH keys, sessions or installed apps.
- Decide whether you want to revoke one specific authorization or all of them.
After revoking
- Reload the Authorized OAuth Apps page and confirm the entry is gone.
- Run the workflow that used the app once, and note whether it now asks you to reauthorize. That prompt is the expected sign the grant was removed.
- If a workflow breaks and you still need it, reauthorize deliberately and review the scopes it requests.
- Keep your account recovery method in place until you are sure nothing else depended on the revoked access.
How to revoke the authorization
Open account Settings, Applications under Integrations, then Authorized OAuth Apps to review access. Source
From the list, open the menu for the specific app you want to remove.
An unrecognized or outdated authorization can be revoked from the app menu; the page also offers Revoke all. Source
Revoke the single entry when you only want to remove one app. The Revoke all option is for when you have reviewed the list and want to clear every authorization; it will affect every app on that page, not just the one you were looking at.
Failure boundaries to keep in mind
- Revoking is not deletion. Removing the grant stops future access through it. It does not remove data the app already stored or copied outside GitHub, and it is not a guarantee of erasure.
- Revoking is not signing out. Your browser session on GitHub is separate; revoking an app does not sign you out, and signing out does not revoke app authorizations.
- An SSH key is not an OAuth app. If the access you are worried about is a key, removing it happens in the SSH and GPG keys settings, not in Authorized OAuth Apps.
- An installed GitHub App is not the same entry. Installation-level access is managed where the app is installed, so check there if the app does not appear in the OAuth list.
- A public username match is not proof. If you are checking whether a handle appears elsewhere, a match on a public profile is a lead, not evidence of ownership. TraceSeek can look up known public usernames across 3,000+ platforms, but it cannot review or revoke GitHub settings for you.
When to treat an authorization as suspicious
You do not need a dramatic story to act. The practical signals are: you do not recognize the app, the permissions are wider than the task it performs, or you cannot remember authorizing it. In those cases, revoking the specific entry is a reasonable step, followed by checking whether anything you rely on stops working. If a workflow does break, reauthorize only after confirming the app is the one you expect and the scopes match what it needs.