top of page
Search

How to Revoke Risky OAuth Grants in Google Workspace and Microsoft 365

How to Revoke Risky OAuth Grants in Google Workspace and Microsoft 365
How to Revoke Risky OAuth Grants in Google Workspace and Microsoft 365

If you’ve ever changed a password and still seen a third-party app pulling data, you’ve met the joy of refresh tokens and consent sprawl. Waldo Security maps every SaaS app, account, and OAuth grant in minutes, flags high-risk scopes, and lets you bulk-revoke or right-size access—then export clean, audit-ready evidence. Start with Instant SaaS Discovery and keep proof tidy with the SaaS Compliance Overview.


First, what counts as “risky” OAuth?

  • Broad, tenant-wide scopes (e.g., “*ReadWrite.All”), especially combined with offline_access (long-lived refresh tokens). Microsoft documents delegated permission grants (“OAuth 2.0 scopes”) and how they’re recorded and removed. (Microsoft Learn)

  • Unverified or unknown publishers requesting sensitive scopes.

  • Old, unused grants that still have refresh tokens in circulation.

The fix has two parts: revoke what exists and constrain what gets approved next.


Google Workspace: revoke, restrict, and reduce blast radius

1) Find and block risky apps (Admin Console)

In the Admin console, go to Security → Access and data control → API controls → App access control. From here you can trust, block, or limit apps by OAuth scope across org units or groups. (Google Help)

Tip: Google added scope-level controls so you can allow an app only the specific API scopes it truly needs (for example, Drive read without Gmail access). (Workspace Updates Blog)

2) Kill existing access

Changing a user’s password can revoke certain mail-related OAuth tokens automatically, but don’t rely on that for full coverage. Use App access control to block or limit the app, which prevents new tokens from being issued and cuts data flow at the API. (Google


3) Raise the floor

  • Block or limit third-party API access to sensitive data for everyone except approved apps. Google’s guidance and updates describe these tenant-wide controls. (Workspace Updates Blog)

  • Ensure “less secure apps” are off (now enforced by Google—OAuth is required). (Google Help)


What to document: the app, scopes affected, who approved it, when you blocked/limited it, and evidence from the Admin Console settings page (plus an export of impacted users if available).


Microsoft 365 / Entra ID: remove the grant and invalidate tokens

1) Lock down future consent

Set an app consent policy so end users can only approve low-risk scopes from verified publishers—or require admin approval for everything. Microsoft’s “Configure user consent” and “Manage app consent policies” docs walk through the options. (Microsoft Learn)


2) Revoke the specific delegated grant (per app)

User-granted permissions are stored as oAuth2PermissionGrant objects. Deleting the grant revokes access for that app; existing access tokens may live briefly, but no new tokens are minted for those scopes. Use Microsoft Graph to DELETE the grant. (Microsoft Learn)

Note: The Entra portal can’t revoke user-consented permissions directly—you must use Graph or PowerShell for that operation. (Microsoft Learn)

3) Invalidate refresh tokens (per user)

To sever any lingering sessions, call revokeSignInSessions for the user (Graph API or PowerShell Revoke-MgUserSignInSession). This resets the token epoch so all refresh tokens are invalid and apps must re-authenticate. (Microsoft Learn)

Fine-grained token revocation per single app isn’t currently supported; you can revoke all refresh tokens for the user, or remove the app’s grant and let current access tokens expire. (Microsoft Learn)

4) (Optional) Admin-consented or app-only permissions

If the risky permission was admin-consented (app-only or tenant-wide), remove it via the Enterprise applications → Permissions blade or with Graph’s permissions APIs (grant/revoke programmatically). (Microsoft Learn)

What to document: the service principal, grant IDs removed, the consent policy in force, and the timestamp when you revoked sign-in sessions.


A safe, repeatable playbook

  1. Inventory first. Pull a full list of OAuth apps across Google Workspace and Entra/M365 with publisher, scopes, last used, and who consented. (This is where Waldo saves hours—you’ll see all apps, even those outside SSO.)

  2. Score risk. Rank by blast radius × persistence × trust (e.g., *.ReadWrite.All + offline_access + unverified publisher).

  3. Revoke in order.

  4. Prevent recurrence. Tighten user-consent policies (Microsoft) and default app access controls (Google). (Microsoft Learn, Workspace Updates Blog)

  5. Prove it. Keep an evidence packet: before/after scopes, grant IDs deleted, token revocation timestamps, and screenshots/exports of policy settings. (Waldo’s SaaS Compliance Overview assembles this automatically.)


Admin quick references (copy/paste)

Google Workspace

  • Console path: Security → Access and data control → API controls → App access control. (Google Help)

  • Use scope-level restrictions where possible to minimize blast radius. (Workspace Updates Blog)

  • Password changes can auto-revoke certain mail tokens, but don’t count on that alone. (Google Help)

Microsoft 365 / Entra ID

  • Set and assign app consent policies; restrict or disable end-user consent. (Microsoft Learn)

  • Revoke grant: DELETE the oAuth2PermissionGrant (Graph). (Microsoft Learn)

  • Invalidate tokens: POST /users/{id}/revokeSignInSessions or PowerShell Revoke-MgUserSignInSession. (Microsoft Learn)


Common pitfalls (and how to avoid them)

  • Revoking tokens but not the grant. The app just asks for a new token. Delete the grant and reset sessions. (Microsoft Learn)

  • Relying on UI only. The Entra portal can’t remove user-consented grants—use Graph/PowerShell. (Microsoft Learn)

  • Letting anyone consent to anything. Enforce consent policies and verified publishers; review exceptions monthly. (Microsoft Learn)

  • Missing Google consumer variants. Combine app blocks with domain claims and scope limits to keep personal accounts from siphoning data. (Google Help, Workspace Updates Blog)


Make it boring (in a good way)

Schedule a monthly sweep: export grants, sort by risk, revoke idle high-risk entries, and snapshot consent policies. Waldo can do the heavy lifting—discover everything, shrink the blast radius, and keep receipts—so revoking risky OAuth becomes a 15-minute hygiene task instead of an incident postmortem. Start with Instant SaaS Discovery and let us turn “mystery apps” into a clean, auditable list.


 
 
 

Comments

bottom of page