Auditing Third-Party OAuth Consent Grants

What it stops This control breaks persistence. Attackers use consent phishing to trick users into granting permissions to a malicious application. This bypasses MFA because the attacker obtains a token rather than a password. The token lasts until it expires or is revoked. Reviewing these grants identifies rogue apps that have established a permanent bridge into the environment. It stops an attacker from reading every email in a mailbox via Mail.Read long after the original phishing session ended. It prevents the silent exfiltration of files from OneDrive or SharePoint by spotting applications with broad scopes that have no business being there. It forces a cleanup of the shadow IT that users install to make their jobs easier, which often provides an accidental open door for an adversary.

What it does not stop It does not prevent the initial compromise. The user still clicks the button and grants the permission. If the attacker is fast, they will dump the data before the admin ever looks at the list. A monthly review is a post-mortem, not a shield. It also fails to address tokens that are already exfiltrated from a device; revoking the grant stops future use but does nothing for the data already gone. Many assume this covers all service accounts. It does not. Admin review of user OAuth grants often misses high-privilege enterprise applications or service principals created by another admin. A rogue app granted Directory.ReadWrite.All at the tenant level will stay invisible to a person only checking user-level consents. Password resets are also insufficient here. Changing a password does not always invalidate an existing OAuth token.

What it looks like when it is working The environment has a defined list of sanctioned applications. The admin console is free of entries for Email Optimizer or PDF Tool that possess full read-write access to the Drive. Audit logs show a pattern of regular, scheduled reviews. There are alerts in the SIEM for any new grant involving scopes like Files.ReadWrite.All or https://www.googleapis.com/auth/gmail.readonly. The process is tedious and largely consists of asking users why they installed an unapproved app before clicking revoke. It is a steady rhythm of administrative housekeeping. Success looks like a dwindling number of over-privileged grants over time.

How to prove it Register a test application in the cloud tenant. Assign it broad scopes, specifically https://www.googleapis.com/auth/drive and Mail.Read. Use a standard user account to authorise this app. The admin must detect this specific grant through the established review process and revoke it without external prompting. Record the exact time of authorisation and the exact time of revocation in a log. A pass is achieved if the token is revoked within 72 hours for 100 per cent of the test accounts used. Note whether the admin merely reset the user password or performed a full token revocation.