in one lineOAuth scope creep is when apps keep permissions far broader than their function needs because nobody reviewed the grant after setup.
the numbers
- 1,000+believed under 10 apps vs 1,000+ actualAppOmni, 2024
- 700+companies reached through one compromised OAuth integrationFINRA on the Salesloft/Drift breach, 2025
- 48%of breaches involve a third partyVerizon DBIR, 2026
1what it is
When an application requests OAuth authorization, it specifies the scopes it wants: the specific permissions it is asking for in your environment. A scope might be "read email," "read and write files," "read calendar," "read contacts," or in the broadest case, full access to the Google Workspace or Microsoft 365 account.
OAuth scope creep refers to the situation where applications hold scopes that are broader than their function requires, typically because scopes were granted without careful review at setup and have never been narrowed since.
A notification tool that asks for full mailbox access is requesting far more than it needs. A document analysis tool requesting write access to all files could operate with read-only access. The user clicks "Allow" during setup, often without examining the specific scopes being requested, and the application holds that broad access indefinitely.
2why it accumulates
Scope creep has structural causes on both the vendor side and the user side.
Vendors request broad scopes by design. An application developer who requests minimal scopes must handle edge cases and additional permission requests as users try features. Requesting broad scopes at the start simplifies development and reduces friction in the user experience. The vendor's incentive is to ask for as much as possible at setup.
Users do not review scopes at authorization. The OAuth authorization screen lists the permissions being requested, but in practice, most users click through without reading it. The permission review step that is technically present in the flow is functionally absent in most user behavior.
Scopes are not reviewed after authorization. Even where organizations conduct periodic OAuth grant reviews, the review typically focuses on which applications have grants rather than on the specific scope each grant carries. An application that is known and trusted may not have its scope examined in the review.
Minimal scope is often not available. Some vendors structure their permission model so that the feature set the user wants is only available with a broad scope. Requesting a narrower scope means losing functionality the user considers essential. The user accepts the broad scope to get the feature.
3what it costs you
Wider breach impact. When an application with a broad OAuth grant is compromised, the attacker has the same access the application had. If that application held full mailbox read access, the attacker can read your organization's email. If it held full file access, they can access and exfiltrate your documents. The blast radius of a compromised application is determined by its scope.
Data flows outside your awareness. Applications with broad scope may transmit data they have access to, not only the data they need to function. A productivity tool with full mailbox access can read any email in the account, including sensitive communications it was never intended to touch. Whether it does or not is determined by the vendor's practices, which you may not have reviewed.
Principle of least privilege violation. Least privilege is a fundamental security control: every system and user should have the minimum access necessary to perform its function. Applications with excessive OAuth scope violate this principle. In security frameworks including ISO 27001, SOC 2, and DORA, least privilege is expected to be applied to all access, including third-party application access.
Compounding risk from grant accumulation. Scope creep and grant accumulation compound each other. An environment with many long-lived OAuth grants, several of which carry unnecessarily broad scopes, has both a volume problem and a permission depth problem. The combination represents a wide access surface that is difficult to account for without tooling.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
Scope data already sits in the identity provider: the admin console export lists each application's granted scopes, and filtering for the high-scope tier, full mailbox access, full file read or write, full account access, read and modify all data, produces the working list. The assessment that follows is functional. What does this application actually do, and does the scope match. A tool that sends email notifications has no functional case for reading the mailbox; a document tool that creates files has none for reading all existing ones. The gap between granted and required is the finding.
Where the vendor supports narrower scopes, the fix is a revoke-and-re-authorize cycle at the minimum scope the function requires, with the vendor's documentation usually naming the minimal configuration. Where broad scope is baked into the vendor's architecture and no narrower option exists, the realistic moves are a direct vendor conversation about why the scope is necessary and whether a narrower option is planned, plus a note in the vendor's file that weighs on the next assessment or renewal. An architecture that demands full account access for a narrow feature is information about the vendor, and it deserves to be priced in.
The durable control is putting scope inside the review cycle. An OAuth review that confirms which applications hold grants but never examines what each grant permits will pass a trusted tool every quarter while it holds the keys to the mailbox. Scope review per grant, at the same quarterly or half-yearly cadence, is what actually catches creep, since creep is by definition invisible at the application-list level.
on the record
your turn
what you can do about it
this week
Open your OAuth grant list and sort by scope, starting with apps that can read all mail or all files.
Remove the ones nobody uses.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →