What is scope?
Scope is one of the most frequently misunderstood pieces of modern authorization. In short, scope is a list of text strings by which a client application declares the level of access it needs, while the authorization server decides how much of it to actually grant.
The key intuition to start from is this: scope does not describe a user's identity or the full set of their privileges in a system. Scope describes what an application can achieve with a specific token. The distinction sounds subtle, but it is the foundation of all delegated authorization. When you log in to a third-party tool "with Google", that tool does not become you — it receives a narrowly defined token that lets it, for example, read your calendar but not change your password or delete your account.
Formally, scope is defined in the OAuth 2.0 specification, RFC 6749, in section 3.3. The standard says scope is a space-delimited list of case-sensitive strings. Importantly, RFC 6749 deliberately does not dictate what those strings should look like or mean — each authorization server defines its own vocabulary of scopes, such as read:messages, contacts_write, or v1.users.read.
It is worth classifying right away what scope is not. Scope is not a technology or a product — it is a protocol element and a design standard. Nor is it an authentication mechanism (it does not answer "who are you"), but rather a mechanism for limiting the privileges delegated to an application.
This is where a common misconception hides: scope is not tied to the login method but to token-based authorization. In a classic email-and-password session login — where the application authenticates its own user and issues no token to a separate application — scope simply does not appear, and access is governed by roles and permissions checked on the server. Scope enters the picture only when a token is issued to an application acting against a separate resource server. Importantly, a password does not rule this out: if password login is part of an OAuth flow (for example in an SPA?SPA: Single-Page Application — a browser-based web app that runs within a single page and calls APIs dynamically instead of reloading full pages calling an API), the resulting token still carries scope. What matters is not the login method but whether a token delegated to a separate API is involved.
Who is behind it?
Scope has no single creator in the sense of a company or a person — it is a product of standardization work carried out within the IETF (Internet Engineering Task Force). The foundation is the aforementioned RFC 6749 from 2012, which describes the OAuth 2.0?OAuth 2.0: an open standard for delegated authorization that lets an application obtain limited access to a user’s resources without handling their password framework. Over time a family of extensions grew around scope, patching the gaps in the original specification.
The most important are:
- OpenID Connect — an identity layer built on top of OAuth 2.0, maintained by the OpenID Foundation.
- the JWT profile for access tokens (RFC 9068).
- resource indicators that bind a token to a specific audience (RFC 8707).
- the token-exchange standard (RFC 8693).
Each of these documents adds something to how scope is issued, carried, and constrained.
In practice, however, it is the large providers — Google, Microsoft, GitHub, Auth0, or Okta — that shape developers' daily experience with scope, because they design the concrete scope vocabularies and consent screens that millions of users encounter.
How does it work?
The whole point of scope reveals itself in OAuth’s three-party relationship. Three parties take part:
- client (application) — the one asking for access,
- authorization server — the token issuer,
- resource server — the API that protects the data.
When an application wants access, it sends the authorization server a request with a scope parameter listing the privileges it wants.
The authorization server holds full power here. It can grant exactly what was requested, it can grant less (a narrower set), but it should never grant something the resource owner did not approve. If the application omits the scope parameter entirely, the server may use a default value defined at client registration or reject the request.
On the resource server side, scope becomes a condition of access. When the token is an opaque string, the API must validate it by querying the authorization server. When the token is a JWT, the API reads it locally, in three steps:
- it verifies the signature using public keys published as JWKS,
- it checks the token’s validity (the exp claim),
- it looks for the required scope in the scope field.
If an endpoint requires v1.write, the API checks whether that string actually appears in the token’s scope claim. A missing scope results in an insufficient-permissions response.
What are its key components?
The scope ecosystem consists of several layers that are easy to confuse.
Layer 1: the scope parameter
The first is the scope parameter itself — the raw list of strings. In a JWT, per RFC 9068, it lands in the payload as a single text field with scopes separated by spaces.
Layer 2: identity scopes (OpenID Connect)
The second layer is identity scopes from OpenID Connect. OIDC introduced a standardized set of scopes that map directly to user profile data:
openid— forces the OIDC-compliant procedure and the return of an identity token (ID Token).profile— grants access to basic claims like name or picture.email— grants the address and the email_verified flag.addressandphone— grant the corresponding contact details.offline_access— maps to no data but forces the issuance of a refresh token, letting the application renew the session without the user present.
Layer 3: claims
Claims are individual fields inside the token, each of which asserts something about the token itself or about its owner. That is the third layer. Scope is one such claim, but it stands alongside many others. The most common are:
scope— what permissions the token carries (for exampleopenid profile email).iss(issuer) — who issued the token.aud(audience) — who the token is intended for, that is the target API.sub(subject) — the identifier of the subject the token is about.exp(expiration) — until when the token is valid.
Separating scope from the other claims matters, because aud becomes crucial when constraining a token’s reach — it indicates which API is allowed to accept the token.
What can it be used for?
The most visible use of scope is social login and delegated access to data. When an application requests access to your Google Drive, it does so through specific scopes. The broad drive grants visibility into all files, while the narrower drive.file lets the application see only the documents you explicitly shared with it through the file picker or that the application itself created. This is a textbook example of how scope selection translates directly into risk.
The second use is API authorization in microservice architectures. Here scope often works in two layers: the resource server first checks whether the token even has the right scope (for example platform:write), and only then whether the associated user has permission for the specific resource or workspace.
The third, increasingly important field is integration with AI agents. Tools based on the Model Context Protocol (MCP) act on someone else's tokens, so how broad a scope they receive determines how much damage a misdirected or hijacked agent can cause.
How does it differ from other approaches?
Most confusion stems from conflating scope with roles, permissions, and claims.
A role (in the RBAC?RBAC: Role-Based Access Control — an access-control model where permissions are assigned to roles (e.g. admin, viewer) and users are granted roles model) describes a user's function in an organization — ADMIN, MANAGER, VIEWER. A role says what the user is allowed to do. Scope, by contrast, says what the application may do on their behalf. If a company administrator logs in to a simple calendar-sync tool, that tool should receive the calendar.read scope rather than inherit their ADMIN role.
Permissions are the final decision made at the resource server: whether a given operation on a specific database row may execute. Scope is an earlier and coarser gate — a pass, not the full access rulebook.
A claim is any key-value pair in a token. Scope is one particular claim, but not every claim is a scope. The Microsoft Graph?Microsoft Graph: Microsoft’s unified API for Microsoft 365 data and services (Entra ID, Outlook, Teams, SharePoint), with a separate model of delegated and application permissions model illustrates this well by splitting permissions into two kinds:
- delegated permissions (scopes) — act on behalf of a signed-in user and are bounded by the intersection with their real rights.
- application permissions — act without a user, in a system-level regime.
| Concept | What it describes | Where it lives |
|---|---|---|
| Scope | what the application can do with the token | request parameter and token claim |
| Role (RBAC) | what the user is allowed to do | identity system / RBAC |
| Permission | whether a specific operation may execute | resource server (API) |
| Claim | an assertion about the subject or token | inside the token |
Scope beyond OAuth
As a named scope parameter, it is an OAuth 2.0?OAuth 2.0: Open Authorization 2.0 — an open standard for delegated authorization (RFC 6749) that lets an application obtain limited access to a user’s resources without their password and OIDC?OIDC: OpenID Connect — an authentication layer built on top of OAuth 2.0 that adds user identity via an ID Token construct (OIDC being a layer on top of OAuth). But the idea itself — narrowing what a credential can do — also lives outside OAuth under other names: self-issued JWTs with a scope claim without any OAuth flow, API keys with attached permissions (for example Stripe restricted keys?Stripe restricted keys: Stripe API keys with a limited, per-resource permission scope instead of a secret key’s full access), token “abilities” in frameworks such as Laravel Sanctum?Laravel Sanctum: a Laravel package for API authentication where tokens are granted ‘abilities’ (scopes) that limit their permissions, caveats in macaroons?macaroons: bearer tokens (Google) with ‘caveats’, nested conditions that progressively narrow the token’s authority, or Kerberos?Kerberos: a network authentication protocol where a ticket is valid only for a specific service tickets scoped to a specific service.
One should watch out for a linguistic trap: the word “scope” means something completely different in other technologies than in OAuth, and has nothing to do with permissions:
- In SAML?SAML: Security Assertion Markup Language — an XML-based standard for exchanging authentication and authorization data between an identity provider and a service, used e.g. in SSO, the
<Scoping>element indicates which identity provider (IdP?IdP: Identity Provider — a system that authenticates users and issues their identity to applications, e.g. in SSO) to use — it does not define permissions. - In LDAP?LDAP: Lightweight Directory Access Protocol — a protocol for accessing directories (e.g. trees of users and groups), common in directory services like Active Directory, “search scope” says how deep to search the directory tree (just the object, one level, or the whole subtree) — it is the breadth of a search, not access.
Key limitations and challenges
The original scope model from RFC 6749 has built-in weaknesses that the industry is still patching.
Consent theater
The most notorious weakness is consent theater. On the consent screen the permissions are described very broadly and work on an all-or-nothing basis — you either accept the whole thing or you don’t use the app. An application that needs to find one email asks for gmail.readonly, which technically means lifelong visibility into the entire mailbox — including the password-reset emails that other services send to your inbox. Reading those alone is enough to take over those accounts. The user sees only "the app wants to read your mail" and almost reflexively clicks "Allow". This illusory consent is a persistent vector for phishing?phishing: phishing — a social-engineering attack where a fraudster impersonates a trusted site or app to steal login credentials or trick the victim into granting access attacks.
Confused deputy
The second weakness is the confused deputy problem. A token issued for one API, if it carries an overly generic scope and is not bound to a specific audience, can be used by a compromised service to query an entirely different API of the same issuer. The answer is RFC 8707 (Resource Indicators?Resource Indicators: an OAuth extension (RFC 8707) where the client uses a resource parameter to name the target API, and the server writes it into the aud claim, binding the token to a specific audience), which makes the client state upfront — via the resource parameter — exactly which API it wants the token for. The authorization server records that address in the token as the aud claim (the token’s audience). Every API can then check whether the token was issued for it, and if aud points to a different API, the token is rejected.
Scope creep
The third challenge is scope creep and dead integrations. Because OAuth delegations do not expire by default, abandoned applications retain their granted high privileges for years. When a company shuts down a domain and someone else buys it, hijacked integrations can become a gateway to user data. The remedy is token exchange (RFC 8693), which allows deliberate narrowing of privileges (downscoping) instead of passing a "thick" token deep into the infrastructure, along with regular cleanup of unused grants.
Why does it matter?
Scope is one of those infrastructure elements the average user never sees, yet it decides the safety of their data every day. Every "Sign in with Google" click, every plugin connected to a corporate Microsoft 365, every AI agent reaching into your mail — all of it rests on how scopes were designed and granted.
The importance of scope grows with two trends. The first is distributed architectures, where a single token travels through a chain of microservices and every unnecessary scope enlarges the blast radius after a potential leak. The second is the explosion of AI agents acting autonomously on someone else's privileges — here the difference between a read-only scope and a write scope can decide whether a faulty prompt ends harmlessly or in disaster.
The industry is clearly heading toward finer granularity: fine-grained tokens?fine-grained tokens: precise access tokens (e.g. in GitHub) that grant narrow, selected permissions to specific resources instead of one broad scope in GitHub replacing the blunt repo scope, narrower Google scopes, and ultimately Rich Authorization Requests?Rich Authorization Requests: an OAuth extension (RFC 9396) where instead of a simple scope list the client sends a structured JSON object describing the requested permissions precisely (e.g. a transfer amount and recipient) (RFC 9396), which let you express structured consent like "a transfer up to $500 to counterparty Y" instead of a single word. The direction is clear — from coarse scope to precise, legible consent. Whoever understands scope today will adapt more easily to this evolution.
Scope began as a simple list of space-separated words and became the core of delegated authorization across the entire internet. Designing it correctly — with respect for the principle of least privilege — is now one of the measures of maturity for any engineer building secure systems.
Sources
- IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
- IETF — RFC 9068: JSON Web Token Profile for OAuth 2.0 Access Tokens — link
- IETF — RFC 8707: Resource Indicators for OAuth 2.0 — link
- IETF — RFC 8693: OAuth 2.0 Token Exchange — link
- OpenID Foundation — OpenID Connect Core (Standard Scopes and Claims) — link
- Google — Using OAuth 2.0 Scopes (Drive scopes) — link
- GitHub Docs — Scopes for OAuth apps and fine-grained tokens — link