Category: OAuth & OIDC

Claim

Also known as: assertion

Simply put

In identity and access management, a claim is a statement about a user or other subject, such as their email address, name, or group membership, that an identity provider asserts to be true. Claims are typically carried inside tokens or assertions and used by applications to make decisions about a user. Note that the general-purpose meanings of 'claim' in law, insurance, and everyday language are unrelated to the IAM sense described here.

Formal definition

A claim is a name-value pair asserting a piece of information about a subject (such as an end user, service, or device), issued and vouched for by an identity provider or authorization server. In practice, claims populate the payload of tokens and assertions, for example, claims within a JWT (such as sub, iss, aud, exp, and identity attributes) or attribute statements within a SAML 2.0 assertion. The presence of a claim reflects what the issuer asserts, not independently verified truth; a relying party typically validates the containing token's signature and issuer before trusting its claims, and a signed token guarantees integrity and authenticity of claims but not their confidentiality unless the token is also encrypted. The specific claims available, their names, and their semantics depend on the protocol, profile, and deployment configuration (for example, OIDC Core standard claims versus custom claims). Distinguishing which claims appear in an ID token versus an access token is out of scope for this base definition.

Why it matters

Claims are the fundamental unit of information that flows between identity providers and the applications that rely on them. When a relying party makes an access decision, showing a user their account, granting entry to a resource, or routing them to the right tenant, it is almost always acting on claims delivered inside a token or assertion. Because so much downstream behavior hinges on these name-value pairs, the accuracy, provenance, and integrity of claims directly shape the security posture of a federated environment.

The central caution is that a claim represents what an issuer asserts, not an independently verified fact. A relying party that trusts claims without first validating the containing token, its signature, issuer, audience, and expiry, can be misled by forged or replayed tokens. It is equally important to remember that signing a token guarantees the integrity and authenticity of its claims but does not make them confidential; claims in a signed-but-unencrypted JWT are readable by anyone who obtains the token. Treating a signed token as though it were also encrypted is a common and consequential misunderstanding.

The term 'claim' also carries unrelated everyday meanings, an insurance claim, a legal cause of action, or a general assertion of a right, that share no technical relationship with the IAM sense. Practitioners writing policy, documentation, or audit criteria should be explicit that they mean the identity-attribute sense to avoid confusion with these general-purpose usages.

Who it's relevant to

Security architects

Architects designing federation and token-issuance flows decide which claims an issuer will assert, how relying parties validate the containing tokens, and whether encryption is needed to protect sensitive claims beyond the integrity that signing provides.

IAM engineers

Engineers implementing OIDC or SAML integrations map standard and custom claims into tokens and assertions, and configure relying parties to validate signature, issuer, audience, and expiry before consuming claim values.

Application developers

Developers building relying-party applications consume claims to make user-facing decisions, and must treat claims as issuer assertions, validating the token first rather than trusting claim contents at face value.

Compliance officers and auditors

Those reviewing access controls need to confirm that claims driving decisions come from trusted, validated tokens, and that sensitive claims are protected appropriately, recognizing that a signed token is not necessarily an encrypted one.

Inside Claim

Claim name (key)

An identifier for the piece of information being asserted, such as sub, email, or a namespaced custom attribute. In JWTs this appears as a key in the token's payload.

Claim value

The asserted data associated with the claim name, for example a subject identifier, an email address, or a group membership. The value is an assertion made by the issuer, not independently verified fact.

Issuer context

The identity provider or authorization server that asserts the claim, typically conveyed via the iss claim. The trustworthiness of a claim depends on trust in its issuer and validation of the token carrying it.

Registered vs. custom claims

Standard claims defined by specifications such as OIDC Core (for example sub, iss, aud, exp) versus application- or deployment-specific custom claims. Registered claims carry defined semantics; custom claims depend on local agreement.

Carrier token

The structure that conveys claims, such as a self-contained JWT payload or a SAML 2.0 assertion. In ID tokens (OIDC), claims typically describe the authenticated user; in access tokens, claims may inform authorization decisions depending on configuration.

Integrity protection

A signature over the token that lets a relying party verify the claims were not altered and originate from the expected issuer. Signing establishes integrity and authenticity but does not, by itself, provide confidentiality.

Common questions

Answers to the questions practitioners most commonly ask about Claim.

Is a claim the same thing as a permission or an authorization decision?

No. A claim is a statement asserted about a subject (such as an email address, group membership, or role attribute) carried within a token or assertion. It is a piece of information, not a decision. Authorization decisions are made by a policy decision point (PDP) that may consume claims as inputs alongside other attributes and policies. Treating a claim as an entitlement conflates identification and authentication data with authorization enforcement; the presence of a claim does not itself grant access, and how a claim influences access depends on the relying party's policy configuration.

Because a claim is inside a signed token, does that mean it is confidential and tamper-proof?

Signing and encryption are distinct protections. A signed token (for example a signed JWT) provides integrity and origin authenticity, allowing a relying party to detect tampering and verify the issuer, but signing alone does not make the claims confidential. Anyone who can read the token can typically decode and view the claims unless the token is also encrypted. If claims carry sensitive data, confidentiality generally requires encryption in addition to signing, depending on the profile and deployment.

Where do claims come from when a token is issued?

Claims are typically populated by the issuer (such as an authorization server or identity provider) from sources including its user store or directory, attributes gathered during authentication, and additional attribute sources it queries. In many deployments some claims are standard registered claims defined by the relevant specification while others are custom or private claims specific to the organization. The exact set and source depend on the issuer's configuration and the requested scopes or profile.

Should I put every attribute I might need into the token as claims?

Not necessarily. Embedding many claims increases token size and can expose more data to any party that reads the token, and stale claims persist until the token expires. In most deployments teams balance including frequently needed claims directly against retrieving other attributes at request time from a source such as a directory or a policy information point (PIP). The right approach depends on token size limits, sensitivity of the data, and how current the values must be.

How should a relying party validate claims it receives?

Validation typically starts with verifying the token itself (signature, issuer, audience, and expiration) before trusting any claim inside it. A relying party should generally check that expected claims are present, that values conform to expected formats, and that claims such as audience and issuer match its configuration. Trusting claim values without first validating the enclosing token's integrity and intended audience can allow forged or misdirected tokens to be accepted; specific checks vary by protocol profile.

Which claims belong in an ID token versus an access token?

The intended purpose differs. An ID token is meant to convey authentication information about the subject to the client, so it typically carries identity-related claims about who authenticated. An access token is meant for the resource server and typically carries claims relevant to authorization context for that resource, though access token contents and whether they are self-contained or opaque vary by deployment. Placing identity claims intended for the client into an access token, or relying on ID token claims for API authorization, can mismatch each token's intended audience and use.

Common misconceptions

A claim in a token is verified, trustworthy fact.

A claim is an assertion made by an issuer about a subject. Its reliability depends on trusting the issuer and validating the token (signature, issuer, audience, expiry). The claim itself is not self-proving.

If a token is signed, its claims are also confidential and hidden from the client.

Signing provides integrity and authenticity, not confidentiality. Unless the token is also encrypted, claims in a self-contained token such as a JWT can typically be read by anyone who holds it. Signing and encryption are distinct protections.

Claims are only about authentication, or claims automatically grant access.

Claims can carry identity information (as in OIDC ID tokens) or attributes used as inputs to authorization decisions, but a claim being present is not an authorization decision. A PDP or application still evaluates claims against policy; identification, authentication, and authorization remain separate steps.

Best practices

Always validate the token carrying a claim before trusting its contents: check the signature, issuer (iss), audience (aud), and expiry rather than reading claim values directly.

Treat claims as assertions from a specific issuer and scope trust accordingly; only accept claims from issuers you have explicitly established trust with.

Do not rely on a signature for confidentiality; if claims contain sensitive data that must not be readable by intermediaries or clients, use token encryption in addition to signing.

Use registered or well-defined claim names with documented semantics where possible, and namespace custom claims to avoid collisions across systems.

Keep authentication claims (such as those in OIDC ID tokens) distinct from claims used as authorization inputs, and evaluate the latter against explicit policy at a PDP or in the application rather than assuming a claim implies access.

Minimize the claims placed in tokens to those actually needed by the relying party, depending on your deployment, to limit exposure of subject attributes.