OAuth Scope Over-Grant in Third-Party SaaS Integrations

Understanding the full lifecycle of an OAuth grant, from consent to orphan, is the key to closing the exposure.

How OAuth became the connective tissue of the enterprise, and why that creates compounding risk

Every time someone clicks "Allow" on a third-party app, they create a standing credential, not a one-time event. The click feels small and the consequence is permanent until someone actively undoes it. AppOmni describes OAuth as a valet key: it hands over specific, scoped access without exposing the underlying password. That is exactly why it feels safe. The feeling is also the problem. A valet key still starts the car, and depending on what's in the glovebox, that's sometimes all a thief needs.

OAuth's spread across the enterprise didn't happen through some grand security decision. It happened because marketing wanted its CRM synced, engineering wanted dev tools wired into project boards, and HR wanted its system talking to Slack. Each connection was a reasonable productivity call made in isolation. None of them were evaluated as a cumulative access map, because nobody was looking at the map. Obsidian Security's research puts a number on how fast that map is growing: integrations rose 123% year over year, with each one requesting an average of 4.7 scopes OAuth Scopes: Permissions & Security Best Practices. That's not some edge case dreamed up by a red team.

The structural result is that most enterprises now run hundreds, sometimes thousands, of active OAuth tokens, and each one is an implicit trust relationship that can reach past the app in front of the user into fourth- and fifth-party vendors nobody at the company has ever heard of. Approval happens fast, scope requests default to broad, and the persistence clock starts ticking the instant someone clicks Allow. That clock doesn't reset. It doesn't pause. It just runs, quietly, for however long the grant survives, which turns out to be a lot longer than anyone plans for.

Why developers request broad scopes and users approve them without scrutiny

When developers are asked why their app requests full mailbox access instead of read-only, the honest answer is usually convenience. Requesting broad permissions upfront means fewer support tickets later, fewer edge cases where a feature breaks because a user granted too little access last year. Scoping precisely takes engineering discipline that most product roadmaps don't reward.

Users, for their part, aren't reading the fine print. Consent screens show checkbox language like "Read your email," a plain-English gloss that hides the actual technical scope string, and approval happens under time pressure rather than deliberation. Nobody's deliberating. It's closer to signing a rental agreement while the movers are already unloading the truck.

Security teams have often treated that click as a business approval, a decision made and closed. It isn't. It's a user action, made under time pressure, with none of the scrutiny a security review would apply. And the data backs up that this isn't a rare failure mode: research cited by Arcade found that 18.53% of websites request excessive OAuth permissions beyond what they actually need, meaning over-scoping is a measurable industry norm, not a rounding error.

The "just in case" logic compounds it. Full-access scopes for drive or mail get granted at setup on the theory that the app might need them eventually, and then nobody revisits the decision once the integration is working. Shadow IT compounds the picture: Spin.ai found the average company runs 975 unknown cloud services against only 108 that IT actually tracks Obsidian Security. Most OAuth grants happen entirely outside any approval workflow Spin.ai Obsidian Security. Spin.ai's research also puts 65% of SaaS applications in active use as unsanctioned, so the majority of these access decisions get made with zero security involvement. Over-grant is the system's default output. It's the system's default output.

The persistence problem: how scopes outlive their original purpose

An OAuth scope granted once stays granted until someone explicitly revokes it. Changing a password doesn't touch it. Enrolling in MFA doesn't touch it. The grant just sits there, live, independent of whatever else changes around the account it's attached to.

That independence turns ordinary employee turnover into a governance liability. When the person who clicked Allow leaves the company, their OAuth grants don't expire with their badge. The app keeps its access regardless of who's still around to vouch for it. Nudge Security's research found that around 70% of IT professionals report security consequences tied to incomplete offboarding, and manual deprovisioning takes an average of 5 hours per departing employee. Multiply that across a company with normal attrition and orphaned grants aren't a possibility. They're arithmetic.

The vendor itself had been acquired and then shut down. None of that mattered to the grant, which sat there for three years with silent, active access to every file in the drive. That's the vendor lifecycle mismatch in miniature: companies get bought, pivoted, or shuttered, but the OAuth grant to the original entity doesn't care and keeps working.

The scale of this gets uncomfortable fast. Data covering 12 million enterprise identities shows a single free-trial workspace spinning up roughly 3 API tokens, 2 unmanaged credential sets, and at least one OAuth grant that's exempt from MFA entirely Cloud Security Alliance Torii. The average mid-market firm runs 291 hidden apps, which works out to roughly 1,700 secrets sitting outside any SIEM rule or vault Cloud Security Alliance Torii. Secrets sprawl tells the same story from a different angle: 28.65 million new hardcoded secrets appeared in public GitHub commits in 2025 alone, a 34% year-over-year jump and the largest single-year increase on record The State of Secrets Sprawl 2026 Cyber Defense Magazine. Nearly 28% of secrets incidents now originate outside code repositories entirely, surfacing in Slack, Jira, and Confluence instead, and those are 13% more likely to get flagged as critical than a leak found in code The State of Secrets Sprawl 2026 Cyber Defense Magazine. Persistence is what turns a one-time misconfiguration into a permanent fixture of the attack surface.

What an attacker can do with an over-scoped token

The scope granted to an app is the blast radius if that app gets compromised, full stop. Read-only access sounds harmless until you consider what "read" actually covers: every email, every document, every calendar entry, all exfiltratable without a single write permission in sight. The Snowflake campaign is a case where read access alone was enough to pull off data theft at serious scale. Read-only doesn't mean low-stakes. It means the attacker doesn't need to leave fingerprints to walk out with everything.

Read/write scopes escalate the damage from theft to active manipulation. A scope like gmail.compose lets an attacker send email as the compromised user, which is a business email compromise attack that walks straight past the email gateway because it's coming from a real, trusted account. Calendar scopes let an attacker reschedule or cancel meetings to create cover for other activity. Document-editing scopes let them slip a malicious link into a shared file or quietly alter a number on a financial record.

Administrative scopes are where it stops looking like theft and starts looking like takeover. AppOmni's analysis notes that admin-level access lets an attacker create new privileged accounts, change configuration settings, and grant itself access to still more integrations. Individually, a lot of these scopes look defensible on paper. Combined across a handful of connected apps, they form what security researchers call toxic combinations, where isolated, reasonable-looking permissions add up to a lateral movement path across the whole company.

None of it touches MFA, because MFA protects the login, not the token. Once a token is issued, multi-factor authentication has nothing left to check. OAuth access paths route around the authentication controls everyone assumes are doing the protecting. Every integration is a privileged relationship, every token a potential breach vector, and most security teams are defending a web of trust relationships they can't fully inventory, let alone monitor in real time.

How attackers have exploited OAuth over-grant in documented incidents

Over 700 organizations, spanning financial institutions, technology companies, healthcare providers, and government agencies, were compromised through the theft and misuse of OAuth tokens granted to a trusted third-party integration in the Salesloft–Drift OAuth supply-chain attack (August 2025) Cloud Security Alliance Cyber Defense Magazine. There was no exploit involved, no clever zero-day. Just stolen OAuth tokens and patience, working against integrations that get connected once and never get audited again, which Cyber Defense Magazine aptly called gift-wrapped backdoors. The financial-services exposure alone triggered compliance obligations across GLBA, SOX, PCI DSS, GDPR, and CCPA.

The breach involved a three-hop chain: an infostealer called Lumma Stealer infected Context.ai's systems in February 2026, harvested an OAuth token, and used it to move laterally into Vercel's internal environment. ShinyHunters resurfaced here too, listing the stolen dataset on BreachForums for $2 million around April 19, 2026 Cloud Security Alliance. Akeyless's read on the incident treats it as a static-secrets and OAuth-scope problem rather than a code vulnerability. Trend Micro flagged the broader context, that March and April 2026 saw an unusually dense cluster of supply-chain attacks all targeting the same structural weakness, the trust boundary between OAuth providers, CI/CD pipelines, and deployment platforms.

UNC6395's campaign followed the identical pattern elsewhere, using stolen OAuth tokens to reach Salesforce and Google Workspace, bypassing MFA entirely by operating one layer below it, at the token itself. The Commvault breach added a wrinkle: attackers used a zero-day, CVE-2025-3928, to get in, then pivoted to stolen OAuth credentials for a SaaS-to-SaaS compromise, with the compromised tokens granting MFA-bypassing access across connected environments. Salesforce's own response tells you how seriously the industry has started taking this: in September 2025, the company pulled OAuth 2.0 device flow from its Data Loader Connected App after a voice-phishing campaign exploited that exact pattern. Across every one of these incidents, the pattern holds. Attackers aren't breaking anything. They're logging in with valid, trusted tokens that the system has no reason to question, and the chain runs from acquisition to token reuse to lateral movement through relationships everyone already trusted. The attacker group ShinyHunters / UNC6395 reused the same playbook across the Gainsight–Salesforce follow-on in November 2025, affecting 200+ additional Salesforce instances Cyber Defense Magazine. According to Obsidian researchers, the blast radius was 10x greater than previous incidents in which attackers infiltrated Salesforce directly Obsidian Security. The Vercel–Context.ai breach spanned February–April 2026, with the initial Lumma Stealer infection in February 2026, Context.ai AWS access detected in March 2026, and Vercel's disclosure on April 19, 2026. The Hacker News reported that the root cause was a Vercel employee granting Context.ai, an AI Office Suite / AI productivity tool, broad OAuth permissions over their enterprise Google Workspace account by selecting "Allow All" permissions. Akeyless reported that customer environment variables (including API keys, database credentials, and deployment secrets) were exposed for a subset of customers.

Why most organizations cannot see their own OAuth exposure

Spin.ai's 2026 audit found that 64% of third-party applications now access sensitive data without any business justification on file, up from 51% just a year earlier Cyber Defense Magazine. That's not a static problem getting managed. It's getting worse, and organizations can't govern what they've never bothered to count.

Shadow IT explains a lot of the gap. Spin.ai's research puts 30 to 40% of IT spending at large enterprises going toward shadow IT, with 65% of SaaS applications in active use never having been sanctioned by anyone. On the non-human identity side, the Cloud Security Alliance's State of SaaS Security research found 46% of organizations struggle to monitor non-human identities at all, and 56% report active concern about overprivileged API access running through SaaS-to-SaaS connections Cloud Security Alliance / Adaptive Security Cyber Defense Magazine. Those aren't small minorities flagging a theoretical risk. That's close to half the industry admitting the lights are off in a room they know is occupied.

Part of the problem is tooling built for the wrong layer. Most organizations lean on platform-native logs that were never designed to catch SaaS-specific attack patterns, and Mitiga Research found that cloud detection and response platforms routinely miss anomalous token reuse because they were built to watch the perimeter, not API-layer behavior. The incident numbers confirm the visibility gap isn't hypothetical. AppOmni's State of SaaS Security Report found 75% of organizations experienced a SaaS security incident in the past year, a 33% jump over the prior year, with 41% of security teams pointing to user permission issues and 29% citing misconfigurations Cyber Defense Magazine Josys / CSO Online.

That's the governance failure underneath all the others. Nobody assigned ownership, so nobody's accountable when the grant outlives its purpose. Spin.ai found that 61% of companies reported a third-party data breach or security incident in the last 12 months Arcade. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year Cyber Defense Magazine. Valence Security's analysis of the Salesforce–Gainsight incident, cited by NHIMG, identifies the root governance failure as treating OAuth grants as informal SaaS administration rather than as non-human identities with owner, scope, expiry, and review cadence.

Controls that address the full lifecycle, not just the moment of consent

The consent screen is where the exposure starts, not where it ends. Controls need to cover the entire lifecycle: the request, the approval, what happens while the token is active, and eventually, revocation.

At the request stage, scope minimization has to become a procurement condition, not a suggestion. That means treating read-only, read/write, full-access, and administrative scopes as categorically different risk tiers, with the riskiest combinations getting specific policy attention rather than blanket approval. It also means requiring a business justification tied to an actual use case before anyone signs off on a broad scope request, instead of approving "full access, just in case" by default.

At approval, the fix is removing user consent as the only checkpoint. A click from an employee is not a security review, and scopes above a defined risk threshold should require IT or security sign-off before the integration goes live. CASB tools and SaaS discovery platforms serve as a compensating control here, catching the shadow IT grants that never went through a formal approval process in the first place.

Once a token is live, the job shifts to watching what it actually does. Detecting anomalous behavior matters just as much: access attempts at odd hours, bulk data reads that don't match normal usage, token reuse appearing from IP ranges nobody recognizes. Real-time visibility into what connected apps are actually doing isn't a maturity milestone to get to eventually. Without it, a stolen token looks exactly like a legitimate one, right up until the moment it doesn't, which by then is usually too late. Josys identifies implementing continuous SaaS discovery, zero-trust frameworks, and CASB coverage as now baseline recommendations for organizations at scale. SOURCE PAGES: what the pages behind the outline's links say.