Claims are factual assertions about a subject, such as email, role, audience, or expiry. They support downstream authorisation and identity checks after access has been granted. Scopes are the request and grant mechanism, so using them to carry data mixes access policy with identity content and weakens governance clarity.
Why tokens should carry claims, not scopes
scopes and claims solve different problems. Scopes ask for permission, while claims describe an authenticated subject or token. Keeping those roles separate makes authorization decisions more predictable, preserves clean token semantics, and avoids turning access requests into a data transport layer for identity facts.
A good mental model is that scopes are about what a client is allowed to request, and claims are about what the issuer can assert. When those are mixed, downstream services have to infer meaning from fields that were never designed for identity assertions, which makes policy harder to reason about and audit.
That separation also matters when access is delegated across services. A token can carry identity assertions through OpenID Connect while scopes remain the coarse grant boundary. If you want the consumer to know who the subject is, who issued the token, or when it expires, those belong in claims because they travel with the token itself.
How the separation keeps authorization and identity clean
Scopes are usually evaluated by the authorizer as a permission boundary: can this client call this API, read this resource, or invoke this operation. Claims, by contrast, are inputs to identity checks, routing, trust decisions, and token validation. That includes facts such as audience, issuer, subject, expiry, tenant, or role when the role is part of the asserted identity context.
This distinction prevents policy drift. If a system uses scopes to carry identity facts, the scope vocabulary starts doing double duty, and every consumer must understand both the access model and the embedded data model. Claims let identity-aware services inspect the token without expanding the grant language beyond its intended purpose.
It also improves interoperability. Different APIs can interpret the same token claims consistently, while scope names tend to be application-specific and operationally negotiated. A token that includes claims can be validated once and then consumed by multiple services, while the scope string still answers the narrower question of what was approved.
Why scope stuffing creates governance and security problems
When teams overload scopes with data, they blur the line between authorization intent and identity content. That makes change control harder, because a modification to access policy can silently change what downstream systems think the token means. It also makes revocation and auditing less precise, since the token no longer cleanly separates permission from assertion.
Claims are also easier to constrain. A validator can check whether a claim is present, well-formed, signed, issuer-bound, audience-bound, and unexpired. Scopes generally do not provide that same descriptive structure, which is why they are a poor place to embed user attributes, entitlement facts, or lifecycle state.
For OAuth deployments, good practice is to treat the token as the place where the issuer asserts facts and the resource server decides whether those facts are acceptable. Standards such as RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9700: Best Current Practice for OAuth 2.0 Security reinforce audience restriction and stronger token handling, which both become harder when scopes are misused as a data carrier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Token claims and validation govern non-organizational identity assertions. |
| AC-3 — Access Enforcement | Scopes express requested and granted access boundaries for resource decisions. | |
| IA-5 — Authenticator Management | Token claims depend on protected token issuance, handling, and expiry controls. | |
| Recommendation — Validate issuer, audience, and token claims before granting resource access. Enforce scope-based access checks at the resource server. Protect token issuance, lifetime, and revocation processes. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Misused scopes can mask authorization intent and weaken function-level decisions. |
| Recommendation — Separate function authorization from identity assertions in token design. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OAuth and OIDC define the boundary between access grants and token claims. |
| Recommendation — Model scopes as grants and claims as token assertions. | ||
Practitioner Guidance
What to verify: Check whether each token field answers a permission question or an identity assertion question. If it answers “what may this client do,” keep it in scopes; if it answers “who or what is this,” keep it in claims.
Decision rule: If a downstream service would still need the value after authorization is granted, it probably belongs in a claim. If removing the value would change the grant decision itself, it belongs in scope or policy.
Common mistake: Do not use scopes to encode roles, tenant IDs, expiry hints, or user attributes just because they are convenient to pass around. That shortcut creates brittle APIs and makes token semantics harder to validate consistently.
Practitioner takeaway: Keep scopes narrow and request-oriented, keep claims descriptive and verifiable, and design the token so authorization and identity checks can be audited independently.