What are OAuth scopes, and which ones carry the most risk?

An OAuth scope is a permission string that tells an application exactly what it's allowed to do with a user's account, from reading a calendar to permanently modifying financial records. Every time an employee clicks "Sign in with Google" or approves a Salesforce integration, they're granting one or more of these scopes, and most of those grants outlive the reason they were approved. The scopes themselves rarely change once granted, but the risk they carry does: an app that was harmless at approval can become a liability the moment its vendor is breached, its maintainer disappears, or nobody remembers it's still connected.

‍

Key takeaways

• An OAuth scope defines the specific permissions an app receives when a user authorizes it, separate from the user's own login credentials.
• Scopes range from narrow (read-only access to one data type) to broad (full account control), and the riskiest scopes are the ones granting persistent, unmonitored access.
• Scope creep and stale scopes, not weak passwords, are the mechanism behind recent SaaS supply chain breaches involving Salesloft Drift, Vercel, and Klue.
• Most security teams have no inventory of which scopes are currently granted across their SaaS estate, which is what makes stale and over-scoped grants so hard to find.
• Reducing OAuth scope risk requires ongoing discovery and revocation, not a one-time review, since new grants accumulate every time an employee connects a new tool.

What are OAuth scopes?

OAuth 2.0, short for open authorization, is the authorization framework that lets one application access data or actions in another application on a user's behalf, without ever seeing that user's password. Scopes are how OAuth limits what the requesting app can do. When an app asks a user to sign in with Google, Salesforce, or Microsoft 365, the consent screen the user sees is really a list of scopes: specific, named permissions the app is requesting, like reading email, viewing files, or editing calendar entries. For the full token exchange behind that consent screen, see what actually happens when you click sign in with Google.

‍

Once the user approves, the identity provider issues an access token, and that token carries the approved scopes with it. Every API call the app makes afterward is checked against those scopes. An app that only requested read access to a calendar can't use that same token to delete files, even if the underlying account technically has permission to do so. That's the theory, at least. In practice, the scopes an app requests are often broader than what it needs to function, and users approve them anyway because the consent screen appears once, takes seconds to click through, and rarely explains what a given scope exposes.

‍

This is also what separates OAuth risk from a typical password compromise. A stolen password can be reset. A live OAuth grant with broad scopes keeps working indefinitely, across every system that token touches, until someone actively revokes it.

‍

OAuth scopes vs. permissions and roles

Scopes, permissions, and roles get used interchangeably, but they answer different questions. A role defines who a person is inside a system (admin, editor, viewer). A permission defines what that role is allowed to do inside that system. A scope defines what a specific application is allowed to do on a user's behalf, and it's constrained by whatever permissions the underlying user or role already has.

‍

That distinction matters for risk assessment. A third-party app requesting a broad scope, like full mailbox access, doesn't grant more power than the user already has. It grants that same power to a piece of software the security team doesn't control, can't audit internally, and often doesn't know exists. The user's own permissions set the ceiling; the scope determines how much of that ceiling gets handed to an external app. This is also where traditional identity and access management falls short: IAM governs the roles and permissions a user has inside systems it already knows about, but it has no visibility into what a third-party app quietly borrows from that access once a scope is granted.

‍

Scopes are also distinct from claims, a concept defined by OpenID Connect (OIDC), the identity layer built on top of OAuth 2.0. Claims describe facts about the user (their name, email, or group membership) returned to the app after authentication. Scopes describe what the app can do. A single sign-on flow that only shares a user's name and email is a claims exchange with minimal scope; an integration that can read, send, and delete messages on that user's behalf is a much broader scope grant, even though both might start with the same "Sign in with Google" button.

‍

Scope risk tiers: from read-only to full account access

Not every scope carries the same risk, and treating them as a single category is how over-permissioned apps go unnoticed. Security teams evaluating OAuth grants generally sort scopes into risk tiers based on what the scope grants and how sensitive the underlying data is.

‍

‍

A scope tied to a refresh token doesn't expire when the user closes their browser or even when they leave the company, unless something actively revokes it. Combine a persistent, offline-capable scope with full read-write access to a sensitive system, and you have exactly the profile that shows up in nearly every recent SaaS supply chain breach.

‍

The tiering matters most at scale, not in any single grant. One employee approving a read-only calendar app is a negligible risk. A thousand employees each approving a handful of apps over several years, with no process for revisiting any of those grants, produces an environment where dozens of full-access or persistent-scope apps are quietly running in the background, unreviewed since the day someone clicked "allow." Security teams that assess OAuth risk one app at a time miss this; the risk isn't any individual scope, it's the aggregate surface area of every scope currently active across the organization.

‍

Vendor-specific scope examples

Scope names and structures differ by platform, which is part of why they're hard to evaluate consistently. A few patterns recur across the platforms most security teams manage.

‍

Salesforce

Salesforce exposes OAuth scopes at a fairly coarse level compared to some platforms. The full scope grants access to essentially everything the authorizing user's profile permits, api scopes access to the REST and SOAP APIs specifically, and refresh_token grants the persistent, offline-capable access described above. Because Salesforce scopes tend to bundle broad categories of access rather than narrow, single-object permissions, a connected app requesting full where it only needs read access to a handful of objects is a common and easy-to-miss over-provisioning pattern. For the full list of Salesforce scopes and what each one exposes, see the Salesforce OAuth scopes reference.

‍

Google Workspace

Google Workspace scopes are more granular, and the granularity is itself a double-edged sword. A scope like gmail.readonly is meaningfully narrower than gmail.modify, which is narrower still than the full mail scope that permits sending and permanently deleting messages. The same pattern holds for Drive: drive.readonly versus the full drive scope, which can read, write, and delete anything in a user's Drive, including shared files. Admin-level scopes like admin.directory.user go further, exposing an org's entire user directory to whatever app requested it. The Google Workspace OAuth scopes reference documents the specific scopes tied to Gmail, Drive, Calendar, and admin directory access.

‍

ServiceNow

ServiceNow ties OAuth access to role-based API scopes rather than the resource-level scopes Google uses, so the practical question is less "what data can this app see" and more "what role is this integration acting as." An integration authorized with an administrative or sys_admin-equivalent role can touch configuration across the platform, not just the tickets or records it was set up to manage. A ServiceNow settings and configuration reference is useful background for teams auditing ServiceNow integrations more broadly.

‍

Across all three platforms, the pattern is the same: the broadest, most convenient scope to request is rarely the narrowest one that would work, and most connected apps default toward convenience. For platforms beyond these three, the OAuth scopes reference hub covers scope guides for other platforms, including Microsoft 365, GitHub, and Slack.

‍

The scope security problems nobody's solving

Most OAuth security advice stops at "review scopes before approving an app." That's necessary but not sufficient: the problems that lead to breaches happen after approval, when nobody's looking at the consent screen anymore.

‍

Apps are over-scoped by default

Developers request the broadest scope that guarantees their integration will work under every configuration, rather than the narrowest scope that covers the specific feature a user needs. A scheduling tool that only needs to read free/busy status often requests full calendar read-write access anyway, because it's simpler to build and test against one scope than several.

‍

Scope creep happens silently

An app's permissions aren't fixed at the moment of approval. Vendors update their integrations, and those updates can request additional scopes that get silently re-approved, especially in enterprise SSO flows where admins pre-authorize scope changes for an entire domain. A tool a security team reviewed and approved eighteen months ago may be operating under a materially different, broader scope today, without anyone re-reviewing it. See investigating an OAuth grant for suspicious activity or overly permissive scopes for the specific signals that indicate a grant has drifted from what was originally approved.

‍

Stale scopes outlive their purpose

An app connected for a single project, a contractor's temporary access, or a tool a team stopped using six months ago typically keeps its OAuth grant active indefinitely. Nobody revokes access to a tool nobody remembers using. That grant, and whatever scope it carries, sits in the environment as a live credential with no one monitoring it. The same gap shows up during offboarding: suspending a departing employee's Google Workspace account doesn't touch the OAuth grants tied to it, a blind spot covered in the hanging chads of suspended Google Workspace users.

‍

Third-party compromise turns every connected app into an entry point

This is the mechanism behind the last year's highest-profile SaaS supply chain incidents. In the Salesloft Drift breach, attackers used compromised OAuth tokens from a connected Salesloft Drift integration to access Salesforce data across hundreds of customer environments, and the broader SaaS supply chain fallout from that breach made clear the exposure extended well past Salesforce itself. A similar pattern played out in the Vercel breach, where a compromised OAuth token gave attackers a path into connected environments, and again in the Klue breach, where a compromised legacy credential led to OAuth token theft and downstream Salesforce data exposure across dozens of organizations. A nearly identical mechanism drove the suspected compromise of Gainsight-connected Salesforce instances, where a stolen OAuth token was used to issue refresh tokens across hundreds of connected Salesforce environments. Every one of these breaches started with one over-permissioned or under-monitored OAuth grant.

‍

Fixing this requires knowing what scopes are currently live across your SaaS estate, which ones are riskier than they need to be, and which ones should have been revoked months ago. A better consent screen doesn't get you there.

‍

Reducing OAuth scope risk starts with visibility

Most security teams can't answer a basic question: which apps, across the entire organization, currently hold OAuth grants, and what scopes do those grants carry? Without that inventory, every recommendation about reviewing scopes or revoking stale access is theoretical. Across Nudge Security's customer base, the average employee holds 88 active OAuth grants, and roughly 40 apps per organization carry programmatic access to sensitive corporate data, most without anyone tracking them in one place.

‍

A manual version of this review does exist at most organizations, and it doesn't hold up under real conditions. It usually means a quarterly access review, a spreadsheet somebody maintains by hand, or a request routed through IT during an audit. That approach can catch the grants someone remembers to look for. It can't catch the app an employee connected eighteen months ago through a personal account, the integration a departed contractor set up and never told anyone about, or the scope change a vendor pushed last month that nobody re-approved. New OAuth grants get created every time an employee signs into a new tool, faster than any periodic review cycle can keep pace with.

‍

Nudge Security's OAuth risk management approach starts by discovering every OAuth grant across an organization's SaaS estate, including grants approved outside any centrally managed SSO flow. From there, each grant is risk-scored by permission scope and the sensitivity of the data it can access, the same approach Nudge Security uses to risk-score SaaS-to-SaaS OAuth grants, surfacing the "data highways," connections with unusually broad, persistent access to sensitive corporate data, that traditional access reviews routinely miss.

‍

Once those high-risk grants are identified, the harder part is acting on them without breaking something a team depends on. Nudge Security's automated revocation clears out unused grants before they become a liability, and its verification-request workflows send a check directly to the person who approved a given app, confirming whether it's still needed before access gets pulled. That verification step matters more than it sounds: revoking an integration a team is actively relying on creates its own incident. Offboarding integration ties this to the employee lifecycle directly, so grants tied to a departing employee's accounts get surfaced and revoked as part of the standard offboarding process, not discovered months later during an audit. Real-time alerts flag new OAuth activity as it happens, which is what closes the loop between "we reviewed scopes once" and "we know what's happening right now."

‍

This is the Workforce Edge in practice: employees connecting tools to get work done is exactly what a modern SaaS environment looks like, and blocking that entirely just pushes the same behavior underground. What matters is knowing what's connected, how much access it has, and having a way to pull that access back the moment it stops being needed. See how Nudge Security gives you that visibility without slowing employees down.