JSON Web Tokens (JWT)

What it is

A JSON Web Token (RFC 7519) is a compact, URL-safe token of three base64url parts — header, payload, signature — commonly used as a stateless bearer token in APIs and SSO (see security:oauth-saml-sso).

Why it matters

Statelessness is convenient, but a JWT’s only real security boundary is its signature. If a library or application trusts a token without verifying the signature, accepts the wrong algorithm, or uses a leaked or attacker-controlled signing key, anyone can mint a token with arbitrary claims.

How it works

• header: token type and signing algorithm (alg).
• payload: claims — issuer (iss), audience (aud), subject (sub), expiry (exp), issued-at (iat).
• signature: HMAC (symmetric shared secret) or asymmetric (RSA/ECDSA public key).

Detection

• alg: none or an algorithm mismatch between header and the expected key type (alg-confusion).
• Tokens with a exp in the past being accepted, or no expiry at all.
• iss/aud not matching the expected identity provider / relying party.
• Two users sharing a symmetric-signature token (suggests a shared secret was exposed).

Mitigation

• Verify the signature with the expected algorithm and key; never accept alg: none or fall back to an untrusted algorithm.
• Validate iss, aud, sub, exp and iat; reject expired and early (skew) tokens.
• Use asymmetric signing so secret material is confined to the signer; rotate keys.
• Do not log tokens; they are bearer credentials.

Investigation

Decode the JWT (header/payload only, never the signature) to inspect alg/claims and confirm validation gaps, then review the issuer’s key-servicing and token-history logs. Use guides:tool-jwt-guide to decode safely and guides:decode-jwt-safely for the safe procedure.