Your Google Workspace Has Hundreds of OAuth Grants. Do You Know What They Can Do?
The Vercel incident is a good reminder: do you actually control what OAuth apps can access your Google Workspace?
The Vercel incident is a good reminder: do you actually control what OAuth apps can access your Google Workspace?
Vercel was breached through a compromised third-party AI tool, Context.ai, whose Google Workspace OAuth app was used to pivot into a Vercel employee’s account and from there into Vercel environments. The malicious OAuth Client ID has been published as an IOC: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
If you’re a Google Workspace admin, check now: Security > Access and Data Control > API Controls > Manage Third-Party App Access. Filter Accessed Apps by that client ID. If it shows up, revoke access and start your IR process.
But the bigger conversation is what your baseline posture looks like before the next one.
Google gives admins a spectrum of control over unconfigured third-party apps. Most orgs leave it at the default: allow users to grant consent to anything. That’s how you end up with hundreds of shadow OAuth grants across your org, many of which nobody remembers authorizing.
A reasonable middle ground: restrict unconfigured apps to “Sign in with Google only.” Users can still authenticate to SaaS tools through their Google account, which means your MFA policy travels with them. To be clear, this isn’t SSO. You’re not getting centralized provisioning, deprovisioning, or session control the way you would with SAML and a proper IdP integration. But it’s a step in that direction, and for the long tail of SaaS tools that will never get a formal SSO integration, it’s meaningfully better than a standalone username and password with whatever MFA the vendor bolted on. Anything requesting broader scopes, like Gmail, Drive, or Calendar access, gets blocked until it’s reviewed and approved through your vendor and third-party risk management process. This also gives you a way to inventory shadow SaaS by reviewing the accessed apps list in Google.
The nuclear option is blocking all third-party app sign-in entirely. That’s maximally restrictive, but you lose the MFA coverage that federated auth provides for SaaS apps that might otherwise have weak auth of their own.
Neither extreme is right for every org. But if you don’t have a documented posture and an approval workflow for OAuth scope grants, the Vercel incident is a reasonable forcing function to build one.
The Google Admin console has everything you need. The process just has to exist.