How to Detect and Revoke Risky OAuth App Grants Before a Breach

Most breaches don't start with a cracked password anymore. They start with a permission you granted and forgot about. That "Sign in with Google" button you clicked to try a note-taking app in 2022 might still hold a live token that can read your email, download your contacts, and see every file in your Drive. Nobody had to phish you. You handed over the keys yourself.

Here's the uncomfortable stat: security researchers repeatedly find that the average corporate Google Workspace tenant has hundreds of third-party OAuth grants, and a meaningful slice of them belong to apps that are abandoned, unmaintained, or outright malicious. In one widely cited analysis of enterprise environments, more than half of connected apps had not been used in over six months, yet their access tokens remained fully valid. Attackers know this. OAuth token abuse sidesteps multi-factor authentication entirely, because a valid refresh token doesn't need your MFA prompt to keep working.

This article walks you through how to find those risky grants, how to judge which ones actually matter, and how to revoke OAuth app grants across Google, Microsoft, GitHub, and social platforms before one of them becomes your incident report. You'll get a repeatable audit process, a worked example with real numbers, and a comparison of the main provider consoles so you know where to look first.

Key Takeaways

• OAuth tokens bypass MFA. A stolen or lingering refresh token keeps working even after you rotate your password.
• Prioritize by scope, not by app name. An app with gmail.modify or drive access is a far bigger risk than one that only reads your public profile.
• Audit every 90 days at minimum. Set a recurring calendar reminder so this becomes routine, not reactive.
• Revoke first, ask questions later. Removing a grant is non-destructive to your data and easy to re-authorize if you actually need the app.
• Cover all four fronts: Google, Microsoft, GitHub, and social logins each maintain a separate list of connected apps.
• Watch for consent-phishing patterns: apps requesting broad scopes with vague names are the classic OAuth attack vector.

What Are OAuth App Grants, and Why They're a Blind Spot

An OAuth grant is a standing permission you gave a third-party app to act on your behalf inside another service. When you click "Allow" on a consent screen, the provider issues the app a token. That token is what the app uses to read your data or take actions, and it typically keeps working long after you stop using the app.

The problem is the asymmetry. Granting access takes one click. Remembering to remove it takes deliberate effort that almost nobody makes. Over years, grants pile up like browser tabs.

Three things make this a genuine blind spot rather than a minor housekeeping issue:

• Tokens outlive your attention. Refresh tokens can remain valid indefinitely on some platforms until explicitly revoked.
• Scopes are often over-broad. A calendar app that only needs to read your schedule frequently requests full read/write access "for convenience."
• MFA doesn't help here. Once a token exists, the app authenticates with the token, not with your login flow. Your shiny new passkey is irrelevant to a grant you made two years ago.

If you've been following the shift toward stronger authentication, our breakdown of passkeys versus password managers after the breaches pairs well with this piece. Passkeys fix login. They do nothing for the OAuth grants you already handed out.

How OAuth abuse actually leads to a breach

The dominant real-world pattern is consent phishing. An attacker registers an app with a trustworthy-sounding name, sends you a link to a legitimate provider consent screen, and asks for broad scopes. You approve it because the domain is genuinely Google or Microsoft. Now the attacker has a token that reads your mail and never triggers an MFA alert. No malware, no fake login page, just a permission you granted.

How to Find Every OAuth App Grant You've Made

Before you can revoke anything, you need a complete inventory. Each major provider keeps its own list in a different corner of its settings. Here's exactly where to look.

1. Google: Go to myaccount.google.com → Security → Your connections to third-party apps & services. This shows every app with access and the specific scopes each holds.
2. Microsoft (personal): Visit account.microsoft.com/privacy → Apps and services that can access your data. For Microsoft 365 work accounts, admins use the Entra ID portal under Enterprise applications.
3. GitHub: Settings → Applications. Note there are two separate tabs: Authorized OAuth Apps and Authorized GitHub Apps. Check both, plus Installed GitHub Apps for organization-level grants.
4. Facebook: Settings & Privacy → Settings → Apps and Websites.
5. X / Twitter: Settings → Security and account access → Apps and sessions → Connected apps.
6. Slack, Dropbox, Notion, and similar SaaS tools: Each has its own Connected apps or Integrations page in workspace settings.

Export or screenshot each list. You want a single working document so you can score and compare grants across services rather than judging each in isolation. If you keep sensitive notes like this, a self-hosted paste and snippet tool such as LionPaste keeps that inventory off third-party clouds where it could itself become a target.

The scopes that should make you nervous

Not all permissions are equal. When you review each grant, flag anything carrying these high-impact scopes:

• mail.read, gmail.modify, Mail.ReadWrite — full inbox access, the crown jewel for attackers.
• drive, Files.ReadWrite.All — access to your entire file store.
• contacts — a launchpad for spear-phishing everyone you know.
• repo (GitHub) — read/write to private source code.
• offline_access — grants a long-lived refresh token, meaning persistent access.
• Any admin or directory scope on a work account.

How to Score and Prioritize Risky Grants

You will likely find dozens of grants. Trying to evaluate them all with equal effort is how audits stall out. Use a simple scoring model so the dangerous ones surface fast.

Rate each grant 1 to 3 on three factors, then multiply for a total risk score:

• Scope power (1–3): 1 = read public profile only, 2 = read personal data, 3 = read/write mail, files, or code.
• Recency (1–3): 1 = used this month, 2 = used in the last year, 3 = no activity in over a year or unknown.
• Trust (1–3): 1 = well-known vendor you actively pay for, 2 = recognized free tool, 3 = unfamiliar, defunct, or vaguely named.

Anything scoring 12 or higher (out of a max 27) goes on the immediate-revoke list. Anything scoring 18+ is a drop-everything priority.

Worked example: auditing a real 34-grant account

Say you run your inventory and find 34 connected apps across Google, GitHub, and two social accounts. Here's how the numbers typically break down after scoring:

• 19 grants score 6 or below (low-scope tools you still use, like your password manager browser integration). Leave them.
• 9 grants score 7 to 11. Review individually; revoke the ones you don't recognize.
• 4 grants score 12 to 17. These include an abandoned email client with gmail.modify you last used 14 months ago (scope 3 × recency 3 × trust 2 = 18). Revoke now.
• 2 grants score 18+. One is a "PDF converter" app you don't remember installing that holds full Drive access (3 × 3 × 3 = 27). This is exactly what a consent-phishing attack looks like. Revoke immediately, then check for any suspicious activity or shared files.

In this scenario you started with 34 grants and, in under 30 minutes, eliminated 6 high-risk standing permissions including one that could plausibly have been an active foothold. That's the entire value of the exercise.

How to Revoke OAuth App Grants on Each Platform

Revocation is fast and non-destructive. Removing a grant does not delete your data inside the app; it simply invalidates the token so the app can no longer reach into your account. If you genuinely need the app later, you re-authorize it in seconds.

Google

1. Open myaccount.google.com/connections.
2. Click the app you want to remove.
3. Review the listed scopes to confirm what it could access.
4. Click Delete all connections (or Remove access). The token is revoked instantly.

Microsoft

1. Go to account.microsoft.com/consent/Manage.
2. Find the app under the permissions list.
3. Click Remove these permissions.
4. For work accounts, an admin should revoke via Entra ID → Enterprise applications → the app → Users and groups or delete the service principal.

GitHub

1. Open Settings → Applications → Authorized OAuth Apps.
2. Click the three-dot menu next to an app and choose Revoke.
3. Repeat under Authorized GitHub Apps.
4. If you revoke a grant with repo scope, also rotate any personal access tokens the app may have generated, and audit recent commits for anything unexpected.

Social platforms

On Facebook, click the app under Apps and Websites and hit Remove. On X, use the Revoke app permissions button on the Connected apps page. Both take effect immediately.

After you revoke high-risk grants

If a revoked app had mail or file access, don't

Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.