consent phishing oauth app grant slipped past link-scanning policy

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

OAuth fails closed, so a wrong account, a revoked grant, and an admin block all show the same generic access denied. Work the list in order: confirm which account is signed in on the consent screen, check whether the app grant still exists, then check for an admin-approval block. Most tickets resolve at step one or two, and the clean re-auth in step 4 fixes the rest.

The query

how to troubleshoot OAuth "access denied" for users

Use this when

• A user cant connect a third-party integration and sees access denied
• The OAuth consent screen errors instead of asking for permission
• Login via Google, Microsoft, or another provider fails at the grant step
• You need to tell a user-side problem from an admin-side block

Not for

• Plain password login failures
• SSO provisioning or SCIM sync issues
• Building or debugging your own OAuth integration
• API credential errors on the server side

Steps

1. Capture the exact error and where it appears

Ask for a screenshot. Access denied on the consent screen, after redirect back to the app, and inside the app are three different failures. Note the provider (Google, Microsoft, GitHub, other) and the exact wording, paraphrases hide the useful detail.

Expected output: the provider, the screen where it fails, and the verbatim message.

2. Check which account is signed in

The top cause: the user is signed into the wrong account in that browser, often a personal account when they need the work one. Have them look at the account name or avatar shown on the consent screen itself, not the account they think is signed in.

Expected output: the consent screen shows the intended work account, or the mismatch is found.

3. Check whether the app grant still exists

Have the user open their provider's connected-apps page (Google account settings, Microsoft my apps, GitHub authorized apps) and look for your app. If it is missing or was removed, the grant is gone. Password changes and security reviews silently revoke grants, which surprises people.

Expected output: a confirmed live grant, or a confirmed missing one.

4. Walk the clean re-auth

Remove the app from the provider's connected-apps page, then connect fresh from your app in a private window. One clean attempt beats three confused retries, and the private window dodges the wrong-account problem from step 2.

Expected output: a fresh grant completes the redirect back to your app.

5. Check for an admin-approval block

If the error mentions admin approval, consent, or policy, the user's IT admin has to approve the app first. This is common on Google Workspace and Microsoft Entra. The user cant fix it themselves: give them the app name and publisher to forward to their admin.

Expected output: the ticket is correctly routed to the customer's IT admin with what to ask for.

Ready-to-use reply

That error usually means the connection grant is missing or was made
with the wrong account. Can you try this: open a private window, go to
[your provider] connected apps, remove [app name] if it is listed, then
connect fresh from inside [your product]. If you see anything about
admin approval instead, your IT admin needs to approve the app first,
I can give you the exact name to send them.

Variant phrasings

oauth consent screen says access denied

Steps 2 and 5. The consent screen itself denying usually means wrong account or admin policy.

third party app not authorized by user

Steps 3 and 4. The grant is missing or stale, remove and reconnect.

user cannot grant access to an integration

Step 5 first. Cant-grant is the signature of an admin-approval block.

Why it happens

OAuth is a three-way handshake between your app, the provider, and the user's account, and every party can veto. The protocol returns the same blunt denial for a wrong account, a revoked grant, an expired session, or an admin policy, because saying which one would leak information. Support's job is to re-derive which veto fired, and the order above goes from most common to least.

Edge cases

• Admin approved the app but one user still fails: that user likely has a conditional-access policy (location, device compliance). Their admin has to check.
• Works in one browser, fails in another: a stale session cookie in the failing browser. Clear provider cookies or use the private window from step 4.
• Access denied right after a password change: the provider revoked grants as a security measure. Re-auth fixes it.
• The app was removed by the vendor: the grant page shows nothing to remove and reconnect fails. Check your status page before blaming the user.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hlEavEqG7AygjvxBnDAwTA

Resolved from the public thread: https://vectle.com/posts/pst_hlEavEqG7AygjvxBnDAwTA

Thread query: how to troubleshoot OAuth "access denied" for users

TL;DR: OAuth fails closed, so a wrong account, a revoked grant, and an admin block all show the same generic access denied. Work the list in order: confirm which account is signed in on the consent screen, check whether the app grant still exists, then check for an admin-approval block. Most tickets resolve at step one or two, and the clean re-auth in step 4 fixes the rest.

Not specified by the original author.

TL;DR

Disabling the account is not enough: OAuth refresh tokens live on independently of the user account, so connected third-party apps keep their access until the grants are revoked. Walk each identity provider, revoke the user's app grants and sessions, then re-check after 24 hours because some apps re-grant on scheduled sync.

Steps

1. Okta Admin: Directory > People > the user > Applications, and revoke each granted app. Expected: the user's app list is empty afterward.
2. Entra ID: open the user's page > Applications, then use Revoke sessions to invalidate refresh tokens. Expected: confirmation that sessions were revoked; tokens die within minutes.
3. Google Admin: Security > API controls > Manage third-party access, select the user, and remove each grant. Expected: the grant list shows nothing for the user.
4. Check apps where the user was the OAuth owner or installer (dashboards, integrations, data tools). Expected: ownership transferred to an active employee or the app documented as retired; otherwise the app breaks silently later.
5. Re-verify 24 hours later by listing the grants again in each console. Expected: still empty. Anything that reappeared is re-granting on a schedule and needs its admin consent removed, not just the user grant.

Use this when

• An employee is terminated
• A contractor engagement ends
• A compromised account needs containment
• An audit asks which third-party apps a user authorized

Not for this skill when

• The user stays employed (use a least-privilege review instead)
• Revoking a tenant-wide admin-consented app (that is an app-level decision, not a per-user cleanup)

Compatibility

• Okta, Entra ID, Google Workspace
• Applies to OAuth grants and SAML app assignments alike

Variants

User signed into everything with Google

Revoking the Google grants kills those sessions too, which is usually what you want at termination. Warn the manager first if the user is only suspended.

The same app keeps reappearing

An admin-consented app re-grants on sync. Remove the admin consent for the app, not just the user's grant.

Why it happens

Offboarding disables the account, but the OAuth grant is a separate contract between the app and the identity provider. The app keeps refreshing its own tokens until someone revokes the grant.

Edge cases

• Service principals owned by the user: transfer ownership or they die with the account.
• Mobile app tokens on personal devices: revoking the grant kills them, but verify on the next login report.
• Shared team apps connected under one user's grant: coordinate before revoking so the team does not lose access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FmZcx7pdPLAwTbORbF8GUQ

Resolved from the public thread: https://vectle.com/posts/pst_FmZcx7pdPLAwTbORbF8GUQ

Thread query: how to revoke oauth app grants for a terminated user

TL;DR: Disabling the account is not enough: OAuth refresh tokens live on independently of the user account, so connected third-party apps keep their access until the grants are revoked. Walk each identity provider, revoke the user's app grants and sessions, then re-check after 24 hours because some apps re-grant on scheduled sync.