Suspicious OAuth App in Google Workspace: How to Investigate

TL;DR. An illicit consent grant is a phishing that asks for permission instead of a password. The user clicks "Allow", and an attacker-controlled app gets a token for their mailbox or Drive that survives a password reset. In the OAuth token log, look for authorize events with Gmail, Drive or admin scopes, unknown app names, grants from a risky IP, and activity events showing the app reading mail at volume. Revoke the token, block the client ID for the organization, then scope what the app read.

The OAuth route is attractive because it sidesteps most of what defenders watch. No password is stolen, 2SV doesn't apply to the API calls, and the access lasts. MITRE tracks the theft of such tokens as T1528 Steal Application Access Token, and mailbox collection through them as T1114.002 Remote Email Collection.

What the OAuth token log records

Google's OAuth log events page and the token activity appendix describe the events:

Google notes a lag of a couple of hours for this log (lag table). If you export an hour after the click, the grant may not be there yet.

Judging an authorize event

Five questions, in order:

1. Which scopes? The scope list is the whole story.

   Scope	Reach	Analyzer severity
   https://mail.google.com/, gmail.readonly, gmail.modify, gmail.send, gmail.settings.*…	Read, send or reconfigure the mailbox	High
   drive, drive.readonly	Every file the user can access	Medium
   admin.directory.*, cloud-platform	Organization-level actions	High
   openid, userinfo.email, drive.file	Sign-in identity, files the app itself created	Not flagged

2. When and from where? A grant minutes after a risky sign-in, from the same hosting IP, is the attacker authorizing their own app with the stolen session. A grant from the user's usual network after a phishing email is a consent phish.

3. What's the name? Lure names imitate utilities: "PDF Viewer", "Document Signer", "Secure Mail". The name is chosen by the app's developer and means nothing on its own.

4. Who else granted it? Pivot on the client ID. A legitimate SaaS tool has many users across time. A lure app appears in a burst, or on one account.

5. Is it verified and approved? Check Security → Access and data control → API controls → Manage third-party app access for the app's status and verification.

Reading activity events

activity shows the token being used. For Gmail you see api_name = gmail and methods such as gmail.users.messages.list, gmail.users.messages.get, gmail.users.settings.filters.create. That last one means the app created a Gmail filter, often the hiding filter of a BEC.

The analyzer flags an app making 20 or more Gmail API calls within 60 minutes for the same user as App reading Gmail through the API at volume. That is collection, not a mail client occasionally syncing. The IPs on these events are the attacker's API infrastructure. Add them to your IP pivot.

Response

1. Revoke for the user: Admin console → the user → Security → Connected applications → remove the app. This is also part of Google's compromised-account procedure.
2. Block for everyone: set the app to Blocked in API controls, by client ID. Otherwise the next phished user re-grants it.
3. Restrict unconfigured apps: Google's app access control lets you stop users from granting access to apps you haven't reviewed, or limit them to sign-in-only scopes. Users can then request access for review.
4. Scope the damage: from the activity events, list methods and time spans. From the Gmail log, check what was forwarded or sent in the same window. num_response_bytes gives a rough sense of volume.
5. Watch admin-side changes: the analyzer also flags admins loosening app controls (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS and similar) as App access controls loosened.

Per-user grants vs domain-wide delegation

Everything above concerns per-user consent: one user, one token, bounded by what that user can access. Domain-wide delegation is different. A super admin lets an API client impersonate any user for the listed scopes, with no user consent at all. It is recorded in the Admin log, not the token log. It gets its own post.

Common false positives

• Backup, archiving, e-signature and CRM tools legitimately ask for full Gmail or Drive scopes. Document them and block the rest.
• Mail clients using OAuth also hold https://mail.google.com/.
• Internal apps built by your own developers. Check the client ID's Google Cloud project owner.

The analyzer has no allow-list yet, so known apps will fire. Treat those findings as an inventory review.

Next: domain-wide delegation risks. Back to the investigation guide, or run your token log through the analyzer.

FAQ

Does a password reset revoke a third-party app's access in Google Workspace?

Don't count on it. An app the user authorized keeps working until its token is revoked. Revoke it for the user (Admin console → user → Security → Connected applications) and block the app for the organization in API controls.

Which OAuth scopes are the most dangerous in Google Workspace?

Full Gmail access (https://mail.google.com/), gmail.readonly / gmail.modify / gmail.send and the Gmail settings scopes, full Drive (drive, drive.readonly), and admin directory or cloud-platform scopes. They give an app the same reach as the user, or more.