As reported by BleepingComputer, the explosive growth of OAuth grants across enterprise SaaS environments has created a governance gap that most security teams are entirely unequipped to manage. The article highlights a critical and often misunderstood reality: OAuth grants operate completely outside the identity controls that organizations have spent years building.
The Identity Adjacency Illusion
The most dangerous misconception in modern cloud security is the belief that SSO and MFA provide comprehensive protection over how applications access corporate data. They don't. OAuth is an authorization protocol — not an authentication protocol — and the tokens it produces persist independently of the user who consented to them. When an employee leaves and their account is deactivated, the third-party OAuth grants they created keep functioning. This is not a design flaw; it's how the protocol works. But it creates a class of orphaned access that existing IAM tools were never built to manage.
The Vercel breach referenced in the article — where a compromised OAuth token from Context.ai provided a pathway into enterprise Google Workspace — is not an anomaly. It's a blueprint. Attackers are recognizing that token theft requires no credential compromise, bypasses MFA entirely, and often goes undetected because most organizations don't monitor OAuth grant activity at all.
Why This Problem Is Accelerating
Three converging trends are making OAuth grant sprawl worse:
With an average of 88 grants per employee and 31 carrying data-level permissions — at a 1,000-person organization that's 31,000 direct paths to sensitive data — manual review is mathematically infeasible. Gartner's projection that 50% of SaaS breaches will involve overprivileged OAuth tokens by 2027 should be treated as conservative.
The Detection Blind Spot
Most SIEM platforms and cloud security tools don't natively surface OAuth grant activity. Microsoft's audit logs capture consent grants in Entra ID, and Google Workspace logs record app token activity, but correlating these across dozens of SaaS providers requires specialized tooling that most organizations haven't deployed. This means security teams typically discover malicious OAuth use after data exfiltration has occurred — not before.
Shield53 Recommendations
Organizations should treat OAuth grant governance as a distinct discipline within their identity and access management program — not a subset of SSO or PAM:
- Inventory immediately: Use your IdP admin portals (Microsoft Entra, Google Workspace Admin Console) to export all existing OAuth grants. Third-party tools like Nudge Security, Obsidian, or AppOmni can automate cross-platform discovery.
- Risk-score every grant: Evaluate grants by data sensitivity accessed, scope breadth (read vs. write vs. admin), app vendor reputation, and grant age. Prioritize revocation of grants older than 90 days with broad scopes.
- Implement consent policies: In Microsoft Entra, enable admin consent workflows for high-privilege scopes. In Google Workspace, restrict third-party app access to whitelisted domains only.
- Build revocation into offboarding: Add OAuth grant revocation to your joiner-mover-leaver process. User deprovisioning is incomplete without it.
- Monitor for anomalous token usage: Alert on API calls from dormant grants, geographic anomalies, or sudden volume spikes from previously quiet applications.
- Establish quarterly OAuth reviews: Include OAuth grant audits in your access review cycle alongside privileged account reviews.
The organizations that survive the next wave of SaaS breaches won't be the ones with the strongest passwords — they'll be the ones that learned to govern the tokens their employees never knew they were creating.
OAuth is not going away. It's the connective tissue of the modern SaaS ecosystem. But treating it as a solved problem because SSO is deployed is a strategic failure waiting to happen. The access paths already exist in your environment — the question is whether you can see them before an attacker does.
