Claims-Based Identity
An identity model where user attributes and permissions are expressed as claims -- name-value pairs -- embedded in tokens or assertions, enabling decoupled and portable identity.
Description
Claims-based identity is a model where a user's identity and attributes are represented as a set of claims -- individual statements (name-value pairs) about the subject, issued by a trusted authority (the identity provider). Claims can represent any attribute: name, email, roles, group memberships, department, clearance level, or custom application-specific properties. These claims are packaged into security tokens (JWTs, SAML assertions) and passed to relying parties (applications) that make access decisions based on the claims.
The power of claims-based identity lies in its decoupling of identity assertion from identity consumption. The identity provider is responsible for authenticating the user and asserting claims, while the relying party only needs to trust the provider and evaluate the claims. This eliminates tight coupling between applications and identity stores, enables federation across organizational boundaries, and supports complex authorization scenarios where decisions depend on multiple attributes from different sources.
In practice, claims appear as JWT claims (sub, email, roles, groups, custom fields), SAML assertion attribute statements, or OIDC ID token claims. Applications should design their authorization logic around claims rather than specific identity provider attributes -- check for a 'role' claim with value 'admin' rather than querying a specific LDAP group. This abstraction allows switching identity providers without changing application authorization code. Claims transformation and enrichment can be performed by the identity provider or a claims transformation pipeline that normalizes claims from different providers into a consistent format your application expects.
Prompt Snippet
Design a claims-based identity model where your JWT access tokens carry standardized claims: sub (user ID), email, email_verified, roles (string array), permissions (string array), org_id, and department. Define a ClaimsTransformer interface that maps provider-specific claims to your internal format -- e.g., map Azure AD's groups claim to your roles array, map Okta's custom claims to your permissions array. Implement authorization middleware that extracts claims from the JWT and evaluates policy rules against them. Use a claims-to-permissions mapping configuration (stored in database or config) to decouple identity claims from authorization decisions, allowing policy changes without redeployment.
Tags
Related Terms
JWT (JSON Web Tokens)
A compact, URL-safe token format that encodes claims as a JSON object, digitally signed for integrity verification and optionally encrypted for confidentiality.
OpenID Connect (OIDC)
An identity layer built on top of OAuth 2.0 that enables clients to verify the identity of the end-user and obtain basic profile information.
SAML
An XML-based open standard for exchanging authentication and authorization data between an identity provider and a service provider, widely used in enterprise SSO.
RBAC (Role-Based Access Control)
An access control model where permissions are assigned to roles, and users are granted roles, simplifying permission management at scale.
ABAC (Attribute-Based Access Control)
An access control model that evaluates policies against attributes of the user, resource, action, and environment to make authorization decisions.
Scope-Based Permissions
A permission model where access tokens carry scope strings that define the specific actions and resources the token is authorized to access.
Identity Provider (IdP)
A trusted service that authenticates users, manages their identities, and issues security tokens or assertions to relying applications.