Scopes and claims in OAuth and OIDC: where each belongs

At a glance

What this is: This article explains the difference between OAuth and OIDC scopes and claims, showing that scopes request access while claims carry factual identity and authorisation data.

Why it matters: IAM, NHI, and autonomous governance teams need this distinction because token design, consent boundaries, and downstream policy checks all fail when permission requests and identity facts are treated as the same control surface.

👉 Read WorkOS's article on scopes and claims in OAuth and OIDC

Context

Scopes and claims are different layers of the same identity flow. A scope asks for a category of access, while a claim states something about the subject or the grant. In OAuth 2.0 and OpenID Connect, conflating those layers usually leads to messy consent design, overly broad tokens, and unclear authorization boundaries across human, workload, and agent-driven access paths.

For IAM practitioners, the useful question is not whether scopes or claims are more important. It is where each belongs in the control model: scopes at request and consent time, claims at token consumption time, and validation at every resource that relies on the token. That separation matters across human identity, NHI tokens, and any agentic workflow that consumes federated identity assertions.

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 matter more than scopes at token consumption time?

A: Scopes tell the authorization server what kind of access was requested, but claims tell the consuming service what is true about the subject, the issuer, and the grant. Resource servers should evaluate claims such as issuer, audience, and expiration because those values determine whether the token can be trusted for that specific request.

Q: What do teams get wrong when they add too many OAuth scopes?

A: They usually try to model data granularity with scopes instead of modeling consent. That creates scope sprawl, harder user approval flows, and brittle policy design. A better pattern is to keep scopes few and stable, then use claims for the detailed facts services need to authorize requests correctly.

Q: How should resource servers validate JWT claims in practice?

A: Every consuming service should check the claims it actually relies on, not just trust upstream login flow validation. At minimum that means verifying issuer, audience, expiration, and any domain-specific claims used for authorization. If a service depends on a claim, it must enforce that claim locally before granting access.

Technical breakdown

OAuth scopes as consent and permission boundaries

A scope is a coarse-grained permission request. In OAuth 2.0, the client asks for categories of access, such as email or profile, and the authorization server decides what to grant. That makes scopes the unit of consent and policy boundary, not the unit of data delivery. Scopes are intentionally broad because they are meant to be understandable to users and manageable by authorization servers. They help prevent access models from collapsing into a list of individual attributes or API fields.

Practical implication: Design scopes around meaningful access categories, not single data elements or implementation details.

Claims in OpenID Connect and JWT access tokens

A claim is a factual statement carried in a token or UserInfo response. In OIDC, claims can describe identity attributes such as name, email, or email_verified, and in JWT access tokens they can also encode audience, issuer, expiry, roles, or tenant data. Claims are consumed after authorization has happened, which makes them the evidence a resource server uses to make a fine-grained decision. Their job is to describe what is true, not what was requested.

Practical implication: Validate the claims each service depends on, especially issuer, audience, expiration, and domain-specific authorization fields.

Scope to claim mapping and token design

OpenID Connect defines explicit mappings between scopes and the claims they unlock. That mapping matters because a single scope can release multiple claims, and one token can carry claims derived from several scopes. The architectural risk is scope sprawl, where teams create too many scopes because they are trying to model data granularity instead of access categories. When that happens, consent becomes hard to understand and authorization logic becomes harder to govern.

Practical implication: Keep the scope set small and use claims for detail, so consent remains legible and policy stays testable.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Scopes are governance boundaries, not data containers. The article correctly separates the request for access from the facts carried in the token, which is the right mental model for OAuth and OpenID Connect. That distinction matters because teams often misuse scopes to model data fields instead of consent boundaries, and that breaks authorization clarity across human identity, service accounts, and delegated workflows. Practitioners should treat scopes as the policy conversation and claims as the policy evidence.

Claim validation at the resource server is where trust is actually enforced. A gateway can inspect a token, but the service that consumes it still has to verify issuer, audience, expiry, and any domain claims it relies on. This is especially relevant where NHI tokens are replayed across services or where federated identities flow through multiple APIs. The practical conclusion is that authorization cannot be outsourced to the first hop in the chain.

Over-proliferating scopes creates consent debt. When teams split access into too many micro-scopes, they make user consent harder to understand and increase the chance of policy drift. Claims are the right place for fine-grained facts such as tenant, role, or entitlement, while scopes should stay at the level of meaningful access categories. The field should see this as a design discipline problem, not a syntax problem.

Token design for human identity and NHI should converge on the same principle: coarse request, precise assertion. Human SSO flows, workload tokens, and federated identity all fail in similar ways when request semantics and assertion semantics are blurred. The strongest governance models keep the approval surface broad enough to understand and the token payload specific enough to verify. Practitioners should standardise that separation across identity programmes instead of reinventing it per platform.

OpenID Connect makes claims usable, but it does not make them trustworthy by default. A claim is only as reliable as the issuer, the audience constraints, and the validation logic applied by the consumer. That is why identity architecture has to treat claims as policy inputs, not as assumed truth. The implication for practitioners is straightforward: build verification into every consuming service, not just into the login path.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility.
• That visibility gap is one reason the Ultimate Guide to NHIs , Key Challenges and Risks remains relevant when teams map OAuth claims, token exposure, and delegated third-party access.

What this signals

Scope discipline will become more important as identity platforms centralise more delegated access paths. When one token is expected to work across multiple services, the difference between a consent boundary and a factual assertion becomes operational, not theoretical. Teams that blur the two will keep creating policy exceptions that are hard to audit and harder to revoke.

As federated identity spreads into machine and agent workflows, claim validation becomes a programme control, not a developer preference. If a workload or agent can present a token, the consumer still has to verify who issued it, who it was meant for, and what facts it carries. That is the boundary between a convenient integration and a governable trust chain.

For practitioners

• Define scopes as consent boundaries Map each scope to a user-understandable category of access, such as read email or access profile data. Avoid turning scopes into a list of fields, and review each one for whether it represents a meaningful approval boundary.
• Move fine-grained data into claims Use claims for tenant IDs, roles, entitlements, and other facts that resource servers need to evaluate access. Keep that detail in token payloads or UserInfo responses rather than creating new scopes for every attribute.
• Validate claims at every consumer Require each API or service to verify issuer, audience, expiration, and any domain-specific claims it depends on. Do not assume validation done at the gateway is sufficient for downstream authorization decisions.
• Limit scope sprawl before it hardens into policy debt Review scope catalogues for redundancy and split only when a distinct consent boundary exists. If the need is simply to express more detail, prefer claims rather than adding another scope.

Key takeaways

• Scopes and claims solve different problems, so treating them as interchangeable weakens both consent and authorization design.
• The scale of the issue is governance, not syntax, because token consumers must validate the claims they depend on or they inherit untrusted assertions.
• The practical fix is simple in principle: keep scopes broad and legible, keep claims precise, and enforce those claims at every consuming service.

Key terms

• OAuth Scope: A scope is a coarse-grained permission request that tells an authorisation server what category of access a client wants. In practice, scopes define consent and access boundaries, not individual data fields. For non-human identities, the same principle applies, but the boundary must still be easy to audit and revoke.
• 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.
• Token Consumption: Token consumption is the point at which a resource server evaluates a token and decides whether to allow access. This is where claims matter most, because the service must verify the assertions it depends on before granting any action. The control fails if validation happens only upstream.
• Consent Boundary: A consent boundary is the line between access a subject can reasonably approve and access that would be too broad or too vague to understand. Good scope design uses consent boundaries to keep approval decisions legible. Claims then carry the detail needed for enforcement after consent has been granted.

Deepen your knowledge

Scopes, claims, and token validation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing federated access for workloads or agents, it is worth exploring.

This post draws on content published by WorkOS: Scopes vs. claims: What they are, how they differ, and when to use each. Read the original.