Cybersecurity glossary
What is a Claim?
Learn what a claim is in identity and access security, how assertions convey attributes about a subject, where claims appear in JWT SAML and OIDC, and how to validate them safely.
Definition
In identity and access security, a claim is an assertion made by an identity provider or authorization server about a subject—such as an identifier, role, group membership, or authentication strength—that relying parties may use after validating the issuer and integrity of the assertion.
Why claims matter
Identity systems need a portable way to say facts about a principal. A claim is that fact: an issuer-backed assertion that a relying party can evaluate after it trusts the assertion’s authenticity.
Claims power single sign-on, API authorization, and zero-trust decisions. They also create risk when applications confuse “data present in a request” with “data attested by a trusted issuer.”
What a claim represents
Subject identity
Stable identifiers that say who the assertion is about.
Context attributes
Email, department, tenant, device posture, or assurance level.
Authentication properties
How and when the subject authenticated, including MFA evidence.
Authorization hints
Roles, groups, and scopes that policies may consume.
From assertion to authorization decision
Issuer authenticates the subject
An IdP or authorization server verifies credentials or federation.
Claims are assembled
Directory attributes and session context become assertion fields.
Assertion is protected
Signatures, encryption, or secure channels protect integrity and sometimes confidentiality.
Relying party validates the issuer
Audience, signature, certificates, and issuer identity are checked.
Claims are normalized
Names and value formats are mapped into the app’s policy model.
Policy decides access
Local rules combine claims with resource and action context.
Claims across common protocols
| Protocol | Claim carrier | Example fields |
|---|---|---|
| JWT / OAuth | Access token payload | sub, scope, aud, exp |
| OpenID Connect | ID token / UserInfo | sub, email, acr, amr |
| SAML | Assertion AttributeStatement | NameID, group attributes |
| Session systems | Server-side session record | user id, roles, auth time |
Safe claim handling checklist
- Trust claims only from configured issuers after integrity validation.
- Separate authentication claims from authorization policy evaluation.
- Prefer short lifetimes for high-churn attributes like roles and groups.
- Reject client-supplied security attributes in request bodies.
- Document claim catalogs and naming conventions for every application.
- Watch for over-exposure of PII inside portable assertions.
- Re-evaluate critical entitlements when assurance requirements change.
- Test how apps behave when mandatory claims are missing or malformed.
The practical takeaway
A claim is an issuer’s statement about a subject. Protocols differ, but the security rule is constant: validate who asserted it, then decide what it means for access.
For JWT-specific encoding and registered fields, continue with JWT Claim and the individual aud, exp, iat, iss, nbf, and sub pages.
Related security terms
JWT Claim
How claims are encoded specifically inside JSON Web Tokens.
Subject Claim (sub)
The claim that identifies who the assertion is about.
Issuer Claim (iss)
Identifies which authority made the assertion.
OpenID Connect (OIDC)
Identity layer that standardizes many user claims.
SAML (Security Assertion Markup Language)
XML assertion format that carries claims/attributes.
Frequently asked questions
What is a claim in simple terms?
A claim is a statement about a user or system—like “this is Alice,” “she is in Finance,” or “she signed in with MFA.” Apps trust those statements only after checking who issued them and that they were not altered.
Are claims the same as permissions?
Not exactly. Claims are assertions of attributes. Permissions are authorization decisions that may be derived from claims plus local policy.
Where do claims appear?
Commonly in JWT payloads, OpenID ID tokens, UserInfo responses, SAML assertions, and proprietary session tokens.
Who is allowed to make claims?
Only issuers your application is configured to trust. A claim from an untrusted party is just unauthenticated data.
What is claim-based authorization?
An approach where access rules evaluate attributes from validated tokens—roles, groups, tenant IDs—rather than only local account lookups.
Can claims be stale?
Yes. Embedded role or group claims can lag behind directory changes until the token expires or is refreshed.
Should apps accept claims from the client body?
No. Security claims must come from validated issuer assertions, not from request JSON the client can freely edit.
References
Explore authoritative guidance and frameworks related to claim.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.