TL;DR: Scopes and claims serve different roles in OAuth 2.0 and OpenID Connect: scopes request categories of access at authorization time, while claims carry concrete facts inside tokens and UserInfo responses, according to WorkOS. Keeping that boundary clear makes consent, token design, and downstream authorization easier to reason about.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: OAuth 2.0 scopes request access categories while OpenID Connect claims carry concrete identity and authorisation facts.
Why it matters: IAM teams need this boundary clear because token design, consent handling, and resource-server authorisation all break down when scopes and claims are treated as interchangeable.
Context
Scopes and claims are often discussed together because they appear in the same OAuth and OpenID Connect flows, but they operate at different points in the authorisation model. Scopes are the access categories a client asks for, while claims are the factual assertions that come back in tokens or UserInfo responses.
For IAM and application teams, the practical issue is not terminology but control design. If scopes are used to represent individual data fields, consent becomes noisy and hard to reason about; if claims are treated as permission requests, downstream authorisation loses precision and auditability.
Key questions
Q: How should security teams design OAuth scopes without creating consent confusion?
A: Treat scopes as broad permission categories that a user can understand and approve. Each scope should represent a meaningful access boundary, not a single attribute or field. Put granular data into claims, then verify those claims at the resource server so the token remains useful without making consent unreadable.
Q: Why do claims belong in tokens instead of being modelled as scopes?
A: 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.
Q: How can security teams tell whether token design is becoming too complex?
A: A good signal is scope proliferation without a matching increase in meaningful access categories. If teams keep adding scopes for single data points, or if the same information appears as both a scope and a claim, the model is drifting. That usually means the consent layer and the data layer have been merged.
A: Gateway checks can filter obvious bad tokens, but they do not replace service-level validation. Each resource server should verify the claims it depends on, including issuer, audience, expiry, and any application-specific attributes. That keeps authorisation decisions aligned with the service that actually enforces them.
Technical breakdown
Scopes as authorisation requests
A scope is a permission request that signals what kind of access a client wants on behalf of a user. In OAuth 2.0 and OpenID Connect, the client submits scopes at authorization time, and the authorization server decides what to grant. Scopes are intentionally coarse-grained so they can represent understandable consent boundaries such as profile, email, or a custom resource scope. They do not describe individual data fields or assertions; they define the category of access being requested.
Practical implication: Model scopes around user-understandable access categories, not around individual attributes or token contents.
Claims as token payload facts
A claim is a key-value assertion about a subject, usually the authenticated user, embedded in a token or returned by the UserInfo endpoint. Claims can be registered, standard, or custom, and they include facts such as issuer, subject, audience, expiration, email, role, org_id, or tenant. In OpenID Connect, claims are the data that downstream services inspect after access has already been granted. They are therefore the payload, not the request.
Practical implication: Treat claims as the data your resource servers validate and use for decision-making, not as a consent mechanism.
How scope-to-claim mapping shapes token design
OpenID Connect defines explicit scope-to-claim mappings, which means one scope can unlock several claims and a single token can carry claims enabled by multiple scopes. That design makes scopes the gatekeeper and claims the output, but only if teams preserve the separation in their own systems. Problems start when teams create too many micro-scopes, mirror claims into scopes, or rely on a gateway to do all validation while downstream services trust token content blindly.
Practical implication: Keep scope sets small and stable, then validate issuer, audience, expiry, and domain-specific claims at each consuming service.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scopes and claims fail for different reasons, so governance should not collapse them into one control plane. Scopes are consent and access categories, while claims are identity and grant facts. When teams blur that line, they either over-expand consent boundaries or under-specify the assertions downstream services need. The result is not just messy token design, but weak authorisation logic that is harder to audit and explain.
Scope inflation is a design smell, not a maturity signal. Adding a new scope for every data field turns an access model into a consent list that users cannot reason about and operators cannot govern cleanly. Claims should absorb the granularity, while scopes stay focused on meaningful access classes. Practitioners should treat excessive scope growth as evidence that the authorisation model has drifted.
Claims belong at consumption time, not as a substitute for upstream access design. Resource servers should validate the claims they rely on, including issuer, audience, expiry, and any domain-specific attributes tied to the decision. That keeps the trust boundary explicit and avoids assuming that a gateway or identity provider has already made every relevant judgement. The practical standard is clear: scopes shape what may be granted, claims shape what may be trusted.
Token clarity is an identity governance issue, not just an OAuth implementation detail. Clean separation between scopes and claims reduces ambiguity across application teams, IAM architects, and auditors. It supports better consent language, cleaner federation design, and more reliable policy enforcement across distributed services. The governance lesson is simple: if access and facts are mixed together, every downstream decision becomes harder to defend.
What this signals
Token architecture gets cleaner when scopes remain the consent layer and claims remain the data layer. That separation matters because distributed systems tend to accrete exceptions once one token carries too many responsibilities. Security teams should watch for any design where a scope is being used as a data wrapper, because that usually signals an authorisation boundary that is too vague to govern consistently.
Resource-server validation is the real control boundary for claims. Once claims drive decisions, every consuming service needs to check the assertions it depends on rather than trusting upstream components to have done the whole job. That pattern becomes especially important in federated environments, where one identity event can be consumed by many services with different policy needs.
For practitioners
- Define stable scope boundaries Limit scopes to broad, user-understandable access categories such as email, profile, or a clearly named resource scope. Avoid creating micro-scopes for individual attributes because that makes consent harder to understand and harder to govern.
- Map data needs to claims Place user identity facts, roles, tenant context, and application-specific attributes in claims rather than in new scopes. Use custom claims when services need precise data without expanding the consent surface.
- Validate claims at each resource server Check issuer, audience, expiration, and any domain-specific claims in every service that consumes the token. Do not assume a gateway check covers downstream authorisation decisions.
- Review token content for scope creep Inspect flows where one requested scope unlocks too many unrelated claims or where teams add scopes just to carry data. Rework those designs so scopes describe access categories and claims describe facts.
Key takeaways
- Scopes define what access is being requested, while claims describe the facts that come back after access is granted.
- The most common design mistake is using scopes for data fields or using claims as if they were consent requests.
- Keeping the two separate produces clearer consent flows, cleaner tokens, and more defensible service-level authorisation.
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-63, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token and claim handling directly affect how APIs trust identity assertions. |
| Recommendation — Validate token authenticity and claim integrity before any API authorisation decision. | ||
| NIST SP 800-63 | SP 800-63C — Federation | OAuth and OIDC scope and claim handling sits inside federated identity flows. |
| Recommendation — Apply federation controls to keep request, grant, and assertion data cleanly separated. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Scopes govern entitlements while claims inform authorisation decisions across services. |
| Recommendation — Align access permissions and authorisations with explicit scope and claim checks. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The article maps directly to OAuth and OIDC implementation and verification concerns. |
| Recommendation — Verify OAuth and OIDC handling so scopes and claims are used for their intended roles. | ||
Key terms
- Scope: Scope is the explicit boundary of what testers are allowed to examine in a security programme. It defines the assets, environments, and techniques that are in bounds and out of bounds, helping prevent irrelevant reports, accidental disruption, and uncontrolled testing of sensitive systems.
- Claim: A claim is a statement of fact carried in a token or returned from a user info endpoint. It can describe identity, issuer, audience, expiry, or domain-specific data such as roles and tenant IDs. For machine and agent identities, claims are verification inputs, not assumed truth.
- Identity Token: A persistent, privacy-preserving reference that represents a person or account without exposing the original sensitive attribute. In practice, it lets systems recognise continuity across channels while keeping raw data out of downstream workflows and reducing the blast radius of identity exposure.
- Userinfo Endpoint: The userinfo endpoint is an identity provider API that returns additional user claims when a client presents a valid access token. It is used when the ID token does not contain enough profile information for the application. Security teams should treat it as a controlled identity data source, not a general-purpose profile store.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org