Scoping OAuth Permissions to Minimum Required Access

OAuth scopes are the permission strings your application requests when it needs access to a protected resource — a user's Gmail inbox, a shared Drive folder, a customer database, or an internal API. Scoping to minimum access means requesting exactly the permissions the task requires and nothing more, a principle that sounds obvious but is violated constantly in practice. Most applications request broader access than they need because asking once for everything is easier than asking repeatedly for the right thing, and most organizations have no systematic process for reviewing what access has already been granted. The result is a growing inventory of live, over-scoped grants attached to dormant apps, departed employees, and vendors that no longer exist, each one representing a token that could be exploited without cracking a single password. RFC 9700, the IETF's consolidated OAuth security guidance published in January 2025, states that access token privileges "SHOULD be restricted to the minimum required for the particular application or use case" — not as a style preference, but as a leakage-mitigation strategy, because a narrower scope reduces the damage radius when a token ends up somewhere it shouldn't.

Why teams over-request scopes by default

Nobody sets out to build an insecure application. Over-scoping happens because asking for broad permissions once, up front, is easier than asking for the right permissions repeatedly, later.

Developers request broad scopes defensively so they never have to revisit the authorization dialog when a new feature lands. Consent screens do not help much either, since users click "Allow" without reading, and that one click grants access that can persist for years without review.

The scope-omission problem compounds this: some authorization servers, when a client omits the scope parameter entirely, issue a token carrying the full permissions of the authenticated user. No scope requested becomes maximum scope granted. Most teams never know to look for this behavior because it is a configuration choice made by whoever runs the server, not something documented in the client-side code.

Permission creep finishes the job. Every new feature adds a scope. Almost nobody removes scopes when a feature is deprecated, because removing them requires testing that nothing breaks, and that testing rarely gets budgeted.

The organizational layer amplifies all of this. Usually no single team owns the list of what applications hold what access. Employees who authorized a tool years ago leave the organization, but their grants stay behind. Material Security's 2026 study of 22,332 connected applications found that 91% of AI and automation apps in the dataset appeared in just the last 16 months, with 325 of 356 first observed since January 2024. More than half of the public, governable apps in that set already hold sensitive or restricted scopes. This is not a case of a few careless developers. It is an organization-wide absence of anyone reviewing what has been authorized.

How bad is OAuth exposure right now

In that same Material Security dataset, 47.2% of applications (10,545 of them) showed no active usage in the past 90 days. A quarter of the total set, 25.8% (5,752 apps), had not been accessed in 180 days or more. Their scopes remain live. Nothing was revoked simply because nothing was being used.

Across the full dataset, 24.5% (5,461 apps) hold at least one active restricted scope using Google's own classification. Narrowing to public, governable apps, that share jumps to 53.4% holding sensitive or restricted scopes, with Gmail and Drive access appearing together consistently.

Other sources point in the same direction. The 2025 State of SaaS Security Report found 75% of organizations experienced a SaaS security incident in the past year, up 33% year-over-year, with 41% of security teams attributing incidents to user permission issues and 29% tying incidents directly to misconfigurations. Orca Security found only 55% of permissions assigned to active AWS IAM roles are ever actually used. OWASP's 2025 Non-Human Identity Top 10 survey found 26% of organizations believe more than half their service accounts are over-privileged. Different systems, same pattern: permissions are granted generously and collected back rarely.

The AI-connected app cohort is the newest and least-reviewed segment. Material Security found 149 applications connected for 12 months or more with no review on record. Exposure is invisible until it is not, and by the time it becomes visible, the review that should have happened eighteen months earlier clearly did not.

Anti-patterns that expand your attack surface

A few specific design choices turn a backlog of unreviewed grants into a serious breach vector.

Scopeless tokens are the sharpest risk. When a client omits the scope parameter and the server fills in full user permissions by default, there is no containment boundary. An attacker who obtains that token does not need to escalate privileges. They already have everything the authorizing user holds.

Coarse-grained scopes create the same problem more slowly. Names like users.manage or admin.all are easy to implement and easy to consent to, and that is exactly the issue: one compromised token now carries access far beyond whatever single operation the application actually required.

Some scopes warrant additional scrutiny based purely on what they expose. Microsoft 365's MailboxSettings.ReadWrite allows an attacker to create mail forwarding rules, enabling mailbox takeover without needing a password. Google Workspace's gmail.settings.sharing carries comparable risk. Any scope touching financial records, health data, or administrative settings requires fine-grained treatment, regardless of how much simpler the broad version would have been to implement.

There is also a structural limit worth understanding: OAuth scopes can never exceed what the authorizing user is permitted to do, which sounds like a safeguard until you account for administrators. When an admin consents to a broad-scope application, that application inherits admin-level access, and the scope system provides no additional guardrail at that point. Scope escalation is a related but distinct flaw in which broken server-side validation allows a client to upgrade a token's permissions after the fact, beyond what was originally granted.

All of this is compounded by one structural fact: tokens outlive the authorization event that created them. Revoking consent does not invalidate tokens already issued. Tokens survive password resets, MFA changes, and in some configurations even account disables. A token is bound to the original grant, not to whether the authorizing user is currently active or in good standing.

Real breaches from over-scoped OAuth grants

Midnight Blizzard, the nation-state actor behind Microsoft's January 2024 breach, obtained access through an OAuth application carrying broad permissions. From there they moved laterally into Microsoft's production systems and exfiltrated sensitive data. No password was cracked. No zero-day was exploited. An over-privileged grant had been sitting unreviewed long enough to become the entry point.

The Salesloft-Drift breach demonstrates the same pattern at supply-chain scale. An attacker obtained persistent refresh token access across more than 700 organizations. The breach went undetected long enough to allow ten straight days of active data exfiltration. Researchers at Obsidian described the blast radius as ten times larger than comparable direct-compromise incidents, because OAuth exposure inside a shared vendor relationship means one weak link can affect hundreds of downstream customers.

The Microsoft 365 consent phishing wave involved fake applications designed to impersonate Microsoft, Adobe, and DocuSign. Close to 3,000 accounts across more than 900 environments were compromised, with the fake applications successfully obtaining authorization approximately 50% of the time. Clicking "Cancel" triggered the same redirect chain as clicking "Allow," meaning the user's intent at the consent screen was irrelevant once the flow had started.

Some campaigns require no software vulnerability at all, only social engineering aimed at OAuth's device authorization grant, exploited systematically against large enterprises.

A common version that never makes headlines: an application called "Campaign Analytics Pro" gets authorized with full Drive read and write access. The employee who approved it leaves the organization. The vendor gets acquired and shut down. The scope grant remains live, attached to no active workflow, reviewed by no one. Every incident above shares the same root cause: the grants that were exploited were old, unreviewed, and over-scoped from the day someone first clicked "Allow."

Design scopes with minimum access first

Good scope design starts with naming conventions. Use a resource.operation pattern: orders:read, orders:write, profile:read, profile:write. Each scope maps to exactly one action on exactly one resource. This makes the scope list self-documenting and makes over-requesting visible in the consent dialog, rather than hidden behind a vague label. Avoid generic top-level names like manage, admin, or all, which obscure what is actually being delegated.

Apply fine-grained scopes wherever the operation carries real risk. Financial transactions, modifications to user data, administrative actions, and health records each warrant their own named scope. Coarse scopes are acceptable for low-stakes, genuinely bundled read operations, but they are not a shortcut for anything touching sensitive data or elevated permissions.

Always specify the scope parameter explicitly. Relying on a server's default hands a security-critical decision to someone else's configuration choice, and that default may be far broader than intended.

Request scopes incrementally. Ask only for what the current action requires, and request additional scopes later, at the point in the user flow where they are actually needed. This keeps initial grants small and makes any subsequent expansion visible and contextually justified, rather than front-loaded and easy to approve without scrutiny.

Separate read and write scopes for every resource, even when there is pressure to bundle them in case write access might be needed later. That reasoning is precisely how overly broad scopes get justified in the first place.

For high-risk operations, treat admin consent as its own authorization gate, documented and enforced at the server level. Pair scope design with token lifetime policy: short-lived access tokens reduce the exploitation window even when a scope ends up broader than intended. Narrow scope combined with short token lifetime provides stronger protection than either control applied alone.

Audit existing grants to close exposure

Start with inventory before touching anything else.

Pull the full list of authorized OAuth applications across every identity provider in scope: Google Workspace, Microsoft Entra ID, Okta, and any others in use. For each application, collect four data points: what scopes it holds, who authorized it, when it was authorized, and when it was last active. Google Workspace and Microsoft 365 both surface a version of this natively. Third-party SaaS security tools exist specifically to aggregate this information across platforms when a single dashboard is insufficient.

Once you have the inventory, sort by risk before making any changes. Tier applications by scope sensitivity (restricted, sensitive, standard) and by recency of use. The Material Security data provides a reasonable starting threshold: 90 days of no activity warrants a review, and 180 days warrants presumptive revocation unless a team can make a documented business case for retention. Applications holding admin-level scopes or access to mail settings, Drive, or financial systems move to the front of the queue regardless of how recently they were used.

Investigate before revoking. Verify whether the person who authorized the application still works at the organization. Confirm whether the vendor is still operating, since acquired-and-shuttered vendors are a high-priority revocation target. Ask the team responsible for the integration whether the current scope set is still required or whether it reflects requirements from a feature that was removed.

Revocation has a mechanical limitation that belongs in every runbook: revoking consent stops new tokens from being issued but does not invalidate tokens already outstanding. Those tokens must be explicitly expired or rotated as a separate step. Where an integration is active and genuinely needed, work with the vendor or internal team to re-authorize with a reduced scope set rather than removing the integration entirely.

AI-connected applications deserve a dedicated review pass. The average application in that cohort had been running for nine months in the Material Security study, and 42% had been connected for over a year with no review on record. This category grew faster than any existing review process was designed to track.

Make minimum scope an ongoing control

An audit addresses the current backlog. It does not prevent the same backlog from accumulating again through the same mechanisms.

Establish policy before any new OAuth application goes live in production. Require scope disclosure and a security review as a prerequisite for deployment, not documentation added after the fact.

Build or configure detection for two specific signals. Flag every new application authorization event, particularly any requesting restricted or sensitive scopes, so nothing is approved without visibility. Flag administrator users authorizing any OAuth application specifically, since those grants automatically inherit elevated permissions and warrant a higher-priority review than a standard user authorization.

Minimum scope is not a project you complete. It is an access management discipline you maintain continuously, the same way you maintain any other ongoing security control.