There’s a small button causing a very large problem.
It usually says Allow.
Someone wants to connect a helpful app to Google Workspace, Microsoft 365, Slack, GitHub, Salesforce, or another business-critical system. The app looks useful. The request seems reasonable. The consent screen appears. We click. Work continues. It feels like a productivity decision, when in reality it’s an access decision.
And that’s how OAuth sprawl begins.
OAuth itself isn’t the villain. OAuth is useful, widely adopted plumbing for delegated access. The problem is what happens when hundreds of users, tools, automations, AI apps, SaaS integrations, and forgotten experiments accumulate OAuth grants without clear ownership, review, expiry, or blast-radius visibility.
OAuth sprawl occurs when access governance falls asleep at the consent screen.
What is OAuth and OAuth sprawl?
Open Authorization (OAuth) is a standard that allows one application to access resources in another application on a user’s behalf without sharing passwords. Instead, users grant specific permissions, and the application receives a token that allows it to perform approved actions. It powers the bulk of modern SaaS integrations, but if those permissions aren’t reviewed and managed, they can accumulate over time, creating hidden access risks.
OAuth sprawl is the uncontrolled growth of OAuth-connected applications, delegated permissions, scopes, refresh tokens, service integrations, and third-party app grants across an organization.
We let apps act on behalf of users or systems, then lose track of what they can access, why they were approved, who owns them, and whether they’re still needed.
OAuth grants aren’t just “connections.” They’re access paths, and rather than stealing passwords, attackers increasingly exploit OAuth by obtaining trusted tokens and permissions that let them access systems exactly as an approved application would.
An OAuth app might read files, inspect email, access repositories, pull customer records, query tickets, export analytics, or interact with cloud-adjacent systems. If the app is compromised, over-permissioned, abandoned, or simply forgotten, that access is a path to an intrusion.
Why OAuth sprawl matters now
Modern business is stitched together with SaaS. That means modern access is also stitched together with SaaS.
We’ve spent years improving login security with MFA, SSO, device posture, and conditional access. Good. Lovely. Necessary. But OAuth sprawl lives after login. Once a user grants an app access, that app may continue to operate via tokens and delegated permissions.
IBM X-Force says attackers are increasingly targeting the wider cloud ecosystem rather than only hardened infrastructure. That includes the trusted relationships, automation layers, developer tools, and SaaS integrations that surround cloud environments.
31% of breaches now start with software vulnerabilities, overtaking stolen credentials as the top initial access path [Verizon’s 2026 DBIR]. Attackers are exploiting systems, integrations, and automation routes, not just phishing people into handing over passwords.
That’s the world OAuth sprawl lives in. Not the old world of one user, one login, one app. The new world is one identity, many apps, many tokens, many permissions, many possible side doors. What could possibly go wrong?
OAuth sprawl with a jetpack
AI tools have made OAuth sprawl worse because they thrive on context.
Every productivity assistant, meeting summarizer, coding helper, sales tool, knowledge bot, and workflow agent wants to connect to something. Calendar. Email. Drive. Slack. GitHub. CRM. Ticketing. Data warehouse. The more context it gets, the more useful it becomes.
Also, it becomes more dangerous when access is reliant on broad permissions.
The April 2026 Vercel incident is a sobering warning. Vercel said the incident originated from a small third-party AI tool whose Google Workspace OAuth app was part of a broader compromise affecting users across multiple organizations.
That’s the modern pattern: compromise the smaller trusted tool, then use its OAuth access to reach the larger environment. It’s surprisingly simple, and it’s delegated access doing exactly what it was allowed to do.
Common OAuth sprawl pitfalls
Most OAuth sprawl comes from boring gaps. Security history is basically the story of boring gaps becoming very expensive.
- First, user consent becomes access provisioning. Someone approves an app, but the approval doesn’t go through the same review as other access.
- Second, scopes are too broad. “Read basic profile” is not the same as “read all files, email, users, repositories, and customer records.” Consent screens are not risk assessments.
- Third, tokens can outlive the business need. The project ends. The trial expires. The employee moves teams. The grant remains. Temporary access has a surprisingly robust survival instinct.
- Fourth, ownership is unclear. Does IT own the app? Security? The user? Procurement? The team that tested it once during a Wednesday all-hands? If nobody owns it, nobody reviews it.
OAuth sprawl and compliance
OAuth sprawl creates an awkward compliance question: Can we prove who or what has access to sensitive systems and data?
For SOC 2 compliance, we need logical access controls, review evidence, vendor oversight, and monitoring. For ISO 27001, OAuth sprawl touches access control, supplier relationships, asset inventory, logging, and privileged access. For PCI DSS, the concern is any OAuth-connected tool that can touch payment data, customer support records, or systems in scope. For GDPR and UK GDPR, the issue is accountability: personal data should only be accessed for clear, limited, justified purposes.
NIST SP 800-63-4 also reflects the direction of travel for identity: digital identity systems need ongoing evaluation, risk-based controls, and stronger attention to federation and connected identity relationships.
OAuth sprawl makes all of that harder when grants are invisible trust chains, unowned, or unreviewed.
Solid OAuth governance
We don’t need to ban OAuth. That would be like banning plumbing because someone left a tap running. We need to govern it.
Good OAuth governance means we can:
- Inventory OAuth apps and grants
- Identify owners
- Review scopes
- Classify access by data sensitivity
- Remove unused grants
- Set expiry where possible
- Monitor token use
- Investigate unusual activity
- Treat OAuth apps as non-human identities
- Apply least privilege and just-in-time access principles
- Keep evidence for audit
Every OAuth grant should have a reason, an owner, a scope, a review path, and a way to remove it.
OAuth sprawl is an access governance problem
OAuth sprawl isn’t only a SaaS security issue. It’s an identity governance issue.
Every OAuth grant is a permission decision. Every third-party app is a potential non-human identity. Every token is a possible access path. Every forgotten integration is a little mystery box with API access. Great for productivity. Less great during incident response.
The fix starts with visibility. We need to know what exists before we can govern it. Then we need ownership, least privilege, review, revocation, and evidence.
OAuth sprawl isn’t a protocol failure.
It’s an access governance failure with a friendly consent screen.
We help teams discover, review, and right-size access across cloud and SaaS environments, including the messy places where permissions quietly pile up. Start a Trustle free trial and see where OAuth sprawl, standing access, and unused entitlements may be increasing your risk, all in as little as 30 minutes.
