Software → Security
Identity Claim
A name-value statement about a subject, authentication event, or authorization context carried in an identity assertion or token.
Why it matters
A name-value statement about a subject, authentication event, or authorization context carried in an identity assertion or token.
Mental model
Identity Claim is part of the identity and access-control surface of a modern system. It should be understood together with authentication, authorization, trust boundaries, token lifetime, key management, and the difference between human and workload identities.
How it is used
Engineers use Identity Claim when designing sign-in, delegated authorization, service-to-service access, or identity federation. The important questions are who issues trust, who consumes it, what the credential or assertion proves, how long that proof remains valid, and how compromise is contained.
Security considerations
- Validate issuer, audience, lifetime, and cryptographic integrity where applicable.
- Apply least privilege and request only the permissions needed.
- Avoid long-lived reusable credentials when short-lived or workload-bound credentials are available.
- Treat redirects, token storage, logout, revocation, and key rotation as part of the protocol design rather than implementation details.
- Log authentication and authorization events without exposing credentials or sensitive token contents.
Common mistakes
- Treating authentication and authorization as the same problem.
- Trusting a token merely because it can be decoded.
- Ignoring token audience, issuer, expiry, replay, or revocation behavior.
- Using browser-oriented flows for machine identities or machine-oriented flows for end users.
- Keeping secrets or refresh credentials in locations that are accessible to untrusted code.