Scopes vs. claims: What they are, how they differ, and when to use each

If you've worked with OAuth 2.0 or OpenID Connect, you've almost certainly encountered the terms scope and claim. They show up in the same flows, often in the same tokens, and it's easy to conflate them. But they serve fundamentally different purposes. This article breaks down what each one is, how they're used, and, most importantly, where the line between them falls.

What is a scope?

A scope is a permission request. It represents a category of access that a client application is asking for on behalf of a user. When an application redirects a user to an authorization server, it includes a list of scopes in the request to declare what it wants to be able to do.

Think of scopes as labels on doors. The client says "I'd like access to these rooms," and the authorization server (often with the user's consent) decides which doors to unlock.

Common examples include:

• openid: signals that the client wants an ID token (required in OIDC flows)
• profile: requests access to basic profile information
• email: requests access to the user's email address
• read:messages: a custom scope granting read access to a messaging resource
• admin: a custom scope granting administrative privileges

Scopes are coarse-grained by design. They don't describe specific pieces of data; they describe categories of access. The authorization server uses the granted scopes to determine what information to include in the token and what API endpoints the token is allowed to reach.

Where scopes appear

Scopes show up at two key moments in an OAuth/OIDC flow:

1. The authorization request. The client includes a scope parameter (a space-delimited string) when redirecting the user to the authorization server.
2. The token response. The authorization server may return a scope parameter indicating which scopes were actually granted, which can be a subset of what was requested.

Scopes are not typically embedded inside the access token itself in a standardized way, though many implementations do include them as a claim within a JWT-formatted access token for convenience.

What is a claim?

A claim is a statement of fact about an entity, usually the authenticated user. It's a key-value pair embedded inside a token (most commonly a JWT) that asserts something concrete: a name, an email, a role, an expiration time.

If scopes are labels on doors, claims are the contents of the rooms behind them. They are the actual data that gets delivered once access has been granted.

Claims come in a few flavors:

• Registered claims are defined by the JWT specification (RFC 7519) and have reserved meanings: iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and others.
• Standard claims are defined by OpenID Connect for user profile data: name, email, email_verified, picture, locale, and so on.
• Custom claims are anything your application defines: org_id, role, plan, tenant, permissions, or whatever your domain requires.

Where claims appear

Claims live inside tokens, primarily:

• ID tokens (always JWTs in OIDC): carry claims about the user's identity for the client application.
• Access tokens (often JWTs, but not required to be): may carry claims about the user and the granted permissions for the resource server.
• The UserInfo endpoint: returns claims as a JSON object when called with a valid access token.

The relationship between scopes and claims

Here's where things click: scopes control which claims appear in the token. They have a gatekeeper-to-payload relationship.

When a client requests the profile scope in an OIDC flow, it's not asking for a blob of data called "profile." It's asking the authorization server to include profile-related claims (name, family_name, given_name, picture, birthdate, etc.) in the ID token or UserInfo response.

The OpenID Connect specification defines these mappings explicitly:

‍

So a single scope can unlock multiple claims. And a single token can carry claims enabled by several different scopes, all merged together.

Key differences at a glance

Common misconceptions

• ‍"Scopes and claims are interchangeable." They aren't. A scope is a request; a claim is a result. You request the email scope, and you receive the email claim. The scope is the input to the authorization process; the claim is part of the output.‍
• "If I need a new piece of data, I add a new scope." Not necessarily. You might just need a new custom claim mapped to an existing scope, or included by default. Adding scopes should be driven by the need for distinct categories of consent or access control, not by individual data fields.‍
• "Access tokens don't have claims." They can, and often do, especially when formatted as JWTs. The OAuth 2.0 spec doesn't mandate the format of access tokens, but JWT access tokens with embedded claims are extremely common and are formalized in RFC 9068.‍
• "Scopes are only an OAuth concept." While scopes originated in OAuth 2.0, the idea of permission categories appears in many authorization systems. OIDC extended the concept by defining standard scope-to-claim mappings for identity data.

Practical guidance

When designing your authorization model, a few rules of thumb help keep scopes and claims in their proper lanes:

• ‍Use scopes to model consent boundaries. Each scope should represent a meaningful category of access that a user can understand and approve. "This app wants to read your email" maps to a scope. "This app wants your email_verified boolean" does not.‍
• Use claims to carry the data your services need. Once you've determined what access has been granted, embed the specific attributes (user ID, roles, permissions, tenant info) as claims in the token. Resource servers inspect claims to make fine-grained authorization decisions.‍
• Don't over-proliferate scopes. A handful of well-defined scopes is easier for users to consent to and for developers to reason about than dozens of micro-scopes. Let claims handle the granularity.‍
• Validate claims at the resource server, not just at the gateway. Every service that consumes a token should verify the claims it cares about: expiration, audience, issuer, and any domain-specific claims relevant to its authorization logic.

Conclusion

Scopes and claims are partners in the OAuth/OIDC ecosystem, but they operate at different layers. Scopes define the boundaries of access at the point of authorization. Claims carry the concrete facts about the user and the grant at the point of consumption. Keeping this distinction clear leads to cleaner authorization models, more predictable consent flows, and tokens that carry exactly the right information to the right places.