8 Third-Party OAuth Grants to Audit and Revoke Now
Third-party OAuth app grants are the standing credentials most teams forget to audit. A token that a user approved once keeps reading mail and files long after that user rotates passwords, enrolls a new MFA device or leaves the company. The fix is mechanical: export every consent grant in your tenant, revoke the eight patterns listed below, and restrict high-risk scopes so future installs require explicit administrator trust. Treat an illicit consent grant as worse than a leaked password, because neither password resets nor multifactor authentication removes that access, because the app lives outside the tenant where those controls operate. The application holds account-level access to Microsoft 365 data without ever creating an organizational account, and it keeps that reach until someone revokes the grant itself.
Why consent grants outlive credentials
Microsoft documents the attack chain explicitly: an attacker registers a multi-tenant application in Microsoft Entra ID that requests access to contact information, email or documents, then tricks a user into consenting through phishing or illicit code injected into a trusted website. Once consent is granted, the app pulls data over OAuth exactly like a legitimate integration, on a schedule the attacker controls. Detection therefore cannot rely on sign-in anomalies, because the app never signs in as a user; the signals live in the consent and token audit trail instead. In the Microsoft Defender portal, search the Purview audit log for Consent to application entries and check whether IsAdminConsent is set to True, which indicates that someone with Global Administrator access might have granted broad data access. Remediation must target the grant, not the account: remove the assignment in the Entra admin center, or run Remove-MgOauth2PermissionGrant for delegated consent and Remove-MgServicePrincipalAppRoleAssignment for application permissions, then disable the service principal if the app itself is hostile.
Eight grant patterns worth revoking
Run this checklist against a full export of grants rather than browsing the admin console one user at a time, because per-user review does not scale past a handful of accounts and misses tenant-wide consents entirely. The first pattern carries the most blast radius: an AllPrincipals consent lets a client application access everyone’s content in the tenant, and Microsoft states that every non-Microsoft application holding it should be reviewed carefully.
| # | Grant pattern | Why it is risky | First action |
|---|---|---|---|
| 1 | AllPrincipals held by a non-Microsoft app | Tenant-wide read or write reach | Revoke unless a business owner confirms it |
| 2 | Mail read combined with mail send | Silent inbox monitoring plus outbound phishing | Split the scopes or drop the send right |
| 3 | Grants with no API traffic since the last audit | Access outlives the project that needed it | Revoke and let the owner re-request |
| 4 | Bland, generic or misspelled display names | Common camouflage for attacker-registered apps | Verify the publisher domain before trusting |
| 5 | Consents owned by departed or reassigned users | Nobody remains to notice abuse | Transfer or revoke during offboarding |
| 6 | Unconfigured apps in Google App access control | No trusted, limited or blocked policy exists | Set an explicit access level per app |
| 7 | Full-access Gmail or Drive scopes | The scopes Google classifies as high-risk and lets you restrict | Replace with narrower, per-file scopes |
| 8 | Two or more apps doing the same job | Duplicated blast radius after any vendor change | Keep one and revoke the rest |
A weekly review that scales
Cadence matters more than tooling. Microsoft’s guidance is to commit to reviewing consent grants on a weekly basis in tenants with many registered apps and a large user base, and the weekly export should become the artifact of record that you diff against. On the Microsoft side, dump every OAuth consent grant and app into a single CSV with the Get-AzureADPSPermissions script, then sort by consent type, permission depth and owning user. On the Google side, budget for lag before trusting a clean list: third-party app details typically appear 24 to 48 hours after a user authorizes the app in Google Workspace, so a review run too soon after an incident can read as empty when grants actually exist.
- Export grants from Entra ID and the Google Admin console accessed-apps list.
- Filter for AllPrincipals consents and full-access mail or file scopes.
- Cross-reference grant owners against current staff and privileged-account lists.
- Check audit logs for Consent to application entries with unexpected admin consent.
- Revoke everything that fails the checklist and record who approved keeping the rest.
- Rescan one week later and diff the two exports to catch new grants.
Block risky scopes by default
Cleanup gets cheaper when the platform refuses the worst grants in the first place. In Google Workspace App access control, changing a Google service to Restricted stops previously installed apps you have not trusted and revokes their tokens, and a user who tries to install an app requesting a restricted scope receives a block message instead of a silent consent prompt. You can still mark specific apps as trusted or allow scopes that are not high-risk for untrusted apps, which keeps legitimate workflows alive while closing the quiet path. In Entra ID, the equivalent move is disabling default user consent and routing every request through the admin consent workflow, so each new grant collects a named approver you can interview later. Pair these defaults with the periodic discipline you already apply elsewhere in your environment: the CI/CD pipeline hardening checklist governs what code may deploy, and the object storage exposure review method shows how an outside-in pass catches what inventories miss. Consent grants deserve the same scheduled, evidence-backed attention as any other standing credential in your tenant.