OAuth 2.0: Authorization, Not Authentication
OAuth 2.0 is frequently misunderstood as an authentication protocol. It is not. OAuth 2.0 is an authorization framework: it defines how a client obtains permission to access resources on behalf of a resource owner. The claims carried in OAuth 2.0 access tokens — and in the OpenID Connect ID tokens layered on top — are the mechanism by which that permission is communicated. Understanding this distinction is foundational to building systems that are both secure and correctly designed.
Access Token Claims
OAuth 2.0 access tokens, when formatted as JWTs (as defined in RFC 9068), carry a specific set of claims relevant to authorization. The scope claim is the most important: it lists the permissions the token grants, expressed as a space-separated string of scope strings. Your resource server must validate that the scope claim contains the required scope before serving any protected resource. Missing or incorrect scope validation is one of the most common authorization vulnerabilities in OAuth-protected APIs.
The client_id claim identifies the OAuth client (the application) that obtained the token, distinct from the sub claim that identifies the user on whose behalf the token was issued. In machine-to-machine flows (client credentials grant), sub and client_id may be identical. In delegated flows (authorization code), they are different entities with different trust levels.
Scopes and Fine-Grained Authorization
Scope design is often an afterthought that becomes a maintenance burden. Scopes that are too broad grant excessive permissions; scopes that are too granular create administrative overhead and confuse application developers. xClaim's scope modeling tools help you design scope hierarchies that balance security with usability, and enforce scope requirements consistently across all your resource servers without duplicating validation logic.
Modern authorization patterns often combine OAuth scopes with claims-based attributes for fine-grained decisions. A token might have the read:documents scope but be further restricted to documents owned by the tenant identified in a custom tenant_id claim. This combination of coarse-grained scopes and fine-grained claim attributes gives you both the administrative simplicity of role-based access and the precision of attribute-based access control.
OpenID Connect: Identity on Top of OAuth
OpenID Connect (OIDC) adds an identity layer to OAuth 2.0 by introducing the ID token: a JWT issued alongside the access token that asserts the authenticated user's identity. The ID token's claims include the sub (stable user identifier), email, name, and other profile attributes from the standard OIDC scopes (profile, email, address, phone).
Critically, ID tokens are for the client application to consume, not for the resource server. The resource server should validate the access token. The client should use the ID token to establish the user's identity in the application session. Passing ID tokens to resource servers or using them for API authorization is a common mistake with real security consequences.
JWKS Key Rotation and Token Verification
Both OAuth access tokens and OIDC ID tokens are signed by the authorization server using private keys. The corresponding public keys are published at a well-known JWKS (JSON Web Key Set) endpoint. Your validator must fetch and cache these keys, verify the token signature using the key identified by the kid header claim, and handle key rotation gracefully by refreshing the cached JWKS when an unknown kid is encountered.
xClaim's JWKS management handles all of this automatically. Keys are cached with configurable TTLs, refreshed on cache miss for unknown key IDs, and distributed across your validator fleet without a single point of failure. When authentication infrastructure is invisible because it just works, that is the xclaim! moment.