OAuth scope creep

what 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.

why 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.

what 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 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.