how to investigate a suspicious OAuth app grant

how to investigate a suspicious OAuth app grant

TL;DR

A suspicious OAuth grant means some third-party app can act as one of your users, so investigate it like the access grant it is. List what scopes the app holds, check who granted it and when, compare the app's name and publisher against the real vendor (typosquats are the classic move), then revoke the grant and kill the user's sessions if it looks malicious. Finish with an org-wide sweep of high-privilege grants, because where there is one bad grant there are usually more.

how to investigate a suspicious OAuth app grant

Use this when

• A user reports an app grant they did not make
• A review flags an unknown third-party app
• You are auditing OAuth consents across the org
• A phishing report mentions a fake login or consent screen

Not for this skill when

• You are building an OAuth app or configuring SSO
• The suspicious access is via password or session theft rather than OAuth (different playbook)
• You need to design an app-approval policy (do the investigation first, policy second)

Steps

1. Inventory the user's current grants

Set ADMINTOKENENDPOINT to the Google Admin SDK directory token-list endpoint for the affected user (documented under "tokens.list" in the Admin SDK reference).

curl -s -H "your auth header access token]" "ADMIN_TOKEN_ENDPOINT" | python3 -c "import json,sys; [print(t['clientId'], t.get('displayText','')) for t in json.load(sys.stdin).get('items',[])]"

Expected: the list of apps holding tokens for that user. Find the suspicious one. For Entra, check Enterprise applications and app consent grants; for GitHub orgs, check third-party application access. Same idea everywhere: who holds tokens for this identity.

2. Read the scopes, that is the blast radius

curl -s -H "your auth header access token]" "ADMIN_TOKEN_ENDPOINT" | python3 -c "import json,sys; [print(t['clientId'], t['scopes']) for t in json.load(sys.stdin).get('items',[])]"

Expected: each app's scope list. Mail read, calendar write, directory access, and especially offline access (which means refresh tokens and persistent access) tell you what the app could have done. Admin-level scopes on a random third-party app are the reddest flag there is.

3. Check who granted it, when, and whether it is real

Look at the consent timestamp and the grantor, and ask the user if they remember authorizing it. Then verify the app itself: compare its name, publisher, and homepage URL against the real vendor. Consent phishing uses lookalike names and pixel-perfect fake consent screens, so a legitimate-looking grant record does not mean a legitimate app.

4. Revoke the grant and kill sessions if it looks bad

curl -s -X DELETE -H "your auth header access token]" "ADMIN_TOKEN_ENDPOINT/[client-id]"

Expected: a success response and the app disappears from the user's grant list. If the app looks malicious rather than merely unwanted, also revoke the user's refresh tokens and active sessions so nothing the app obtained keeps working, then have the user re-authenticate.

5. Sweep the org for similar grants

Export all third-party grants org-wide, sort by privilege (admin scopes first, then mail and file read, then offline access), and review the top of the list. Attackers who land one consent phish usually try more users, so check whether anyone else granted the same app.

Variant: GitHub OAuth app audit

In org settings, review third-party application access: which OAuth apps can see org repos and what scopes they hold. Revoke anything unrecognized and restrict future grants to owner approval.

Variant: user-reported "I did not authorize this"

Check the grant timestamp against the user's activity. Consent phishing often follows a phishing email by minutes. If the timing lines up with a reported phish, treat the user's other grants as suspect too.

Variant: marketplace and chat-app integrations

Slack, Atlassian, and similar marketplaces have their own OAuth grants with their own scopes. Audit them the same way: list, read scopes, verify the publisher, revoke the unknowns.

Why this happens

OAuth consent is one click, and users are trained to click through permission screens. Attackers abuse that with fake apps that request broad scopes through the real OAuth flow, so everything looks legitimate in the logs: a real user, a real consent, a real token. The malicious part is entirely in which app got the token, which is why publisher verification matters more than log analysis here.

Edge cases and pitfalls

• Revoking breaks the integration for the user. Confirm before revoking broadly, and tell them what you revoked and why.
• Some scary-looking apps are first-party (Google, Microsoft). Check the publisher before panicking.
• Offline access scope means the app keeps working until tokens are revoked. Deleting the grant without revoking tokens leaves access alive.
• Users re-grant revoked apps when prompted. If the app was malicious, tell the user not to re-authorize it.
• Admin-consented apps affect the whole org, not one user. Those get priority in the sweep.
• Keep a list of approved apps. Investigations go faster when "known good" is written down somewhere.

Tool notes: the examples use the Google Admin SDK Directory API tokens endpoints. Entra investigations use the Entra admin center or Microsoft Graph consent grant APIs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkf4WdnSXKkn1-D8YT7eAA