Stop Shadow SaaS in 2 Clicks: Lock Down Third-Party OAuth in Google Workspace

TL;DR

Google Workspace has a switch called App access control that denies every unconfigured third-party OAuth app access to your Workspace data by default. Turn it on and only apps you explicitly whitelist by OAuth Client ID can touch Gmail, Drive, Calendar, or even do Sign in with Google. Path: Security → Access and data control → API controls → App access control. Set unconfigured apps to Blocked. Whitelist what you trust. Block everything else.

What the setting actually does

When you flip the switch, Workspace blocks all OAuth 2.0 scopes for any app you haven't explicitly trusted — across web and mobile. That includes login scopes, so users can't even use their Workspace account to sign into an untrusted third-party site.

• Whitelist is keyed on the app's OAuth Client ID.
• Users who try to authorize an untrusted app see an authorization error (you can customize the message).
• There is no end-user override — blocked means blocked until an admin approves.
• Default state is OFF. You have to opt in.

Why it matters

Every time an employee clicks “Sign in with Google” on a random productivity tool, they're potentially granting that app scopes against your corporate Drive, Gmail, Calendar, or Contacts. Two categories of risk sit on top of that default-permissive model:

• Consent phishing. An attacker registers a legit-looking OAuth app (“Google Docs Viewer”, “Secure Invoice”) and tricks a user into granting gmail.readonly or drive. No password theft required — the victim literally clicks “Allow.” The 2017 worm that hit a million Gmail users worked exactly this way.
• Shadow SaaS. Teams sign up to dozens of tools with corp accounts. Each one holds a long-lived OAuth token. When someone leaves, the tokens keep working until they're revoked — assuming anyone notices.

Setting unconfigured apps to Blocked closes both. Malicious apps fail silently; shadow tools fail loudly at the consent screen and route through IT.

How to turn it on

1. Open the Admin console.
2. Go to Security → Access and data control → API controls.
3. Open App access control.
4. For Unconfigured third-party apps, choose Blocked.
5. Add your trusted apps by OAuth Client ID under the Configured apps list (Trusted grants access to restricted scopes).
6. Customize the error message so users know how to request access.

That's it. Two clicks to block the world, plus whatever time it takes to build your allowlist.

Technical facts

Who should flip this switch

• Regulated orgs (health, finance, legal) needing a provable audit trail of which third parties touched user data.
• Security-conscious startups killing shadow SaaS before the surface sprawls.
• Any team that just survived a consent-phishing scare — this is the definitive fix.
• IT admins who want to force new SaaS adoption through a ticket, not a personal OAuth grant.

Limitations & trade-offs

• High blast radius if you flip it cold. With an empty whitelist, every existing Zapier, Notion, Slack, AI tool, calendar sync, etc. that relies on OAuth will break at next token refresh. Build your allowlist first.
• Ongoing curation cost. Every new app a team wants = a ticket and an OAuth Client ID lookup. That's the feature, not a bug — but budget for it.
• Rich audit logs are gated. Security dashboard OAuth charts need Business Plus or Enterprise. Business Standard gets the basic audit log.
• No end-user override. Blocked is blocked. If you don't expose a request-access flow, expect support tickets.

Recommended rollout

1. Audit first. Pull the OAuth Token audit log for the last 90 days. Identify which apps, users, and scopes are actually in use.
2. Revoke stale grants. Kill tokens for apps no one uses anymore.
3. Build the whitelist. Collect OAuth Client IDs for sanctioned apps — most vendors publish them in help docs.
4. Pilot by OU. Start with IT or security team. Watch for breakage for 1–2 weeks.
5. Customize the error message with a link to your access-request form.
6. Roll out domain-wide. Then triage the “Apps pending review” queue weekly.

Bottom line

OAuth consent is the most under-defended doorway in most Workspace tenants. “Sign in with Google” is convenient and exactly that convenience is the attack surface. Two clicks in Admin console flip your org from default-allow to default-deny, and the cost is a whitelist you should have been keeping anyway.

Nguồn: Google Workspace Admin Help, Workspace Updates, Google Workspace Blog, @acceleratooooor.