Notifications
Clear all
Topic starter
06/06/2026 11:17 am
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.
NHIMG editorial — based on content published by WorkOS: Scopes vs. claims: What they are, how they differ, and when to use each
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define scopes as consent boundaries Map each scope to a user-understandable category of access, such as read email or access profile data.
- Move fine-grained data into claims Use claims for tenant IDs, roles, entitlements, and other facts that resource servers need to evaluate access.
- Validate claims at every consumer Require each API or service to verify issuer, audience, expiration, and any domain-specific claims it depends on.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The specific OAuth and OIDC flow steps where scopes are requested and claims are returned
- The claim mappings tied to openid, profile, email, address, and phone scopes
- Practical token design examples showing when to use custom claims instead of adding new scopes
- The article's own comparison table that distinguishes scope, claim, location, and purpose
👉 Read WorkOS's article on scopes and claims in OAuth and OIDC →
Scopes vs. claims in OAuth and OIDC: are your controls clear?
Explore further
06/06/2026 12:00 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Scopes and claims in OAuth and OIDC: where each belongs
