JWT

A JWT has three base64url parts: header (alg, kid), payload (claims such as iss, sub, aud, exp, nbf, jti) and signature. It is signed, not encrypted, by default: anyone can read the claims. Verifiers fetch the issuer's public keys from a JWKS endpoint and check the signature locally, which is why JWTs suit distributed APIs.

Validation must pin the algorithm, check iss, aud, exp and nbf with small clock skew, and select keys by kid only from the expected issuer. RFC 8725 is the best-practice reference.

Classic attacks: alg: none, algorithm confusion (an RS256 public key used as an HS256 secret), kid injection into file paths or SQL, and fetching keys from a jku URL the attacker controls. The design issue is revocation: a stateless token is valid until it expires, so keep lifetimes short or add a deny list keyed on jti.

{ "alg": "RS256", "kid": "2026-11", "typ": "JWT" }
{ "iss": "https://id.example.com", "sub": "u_8f21", "aud": "api.example.com",
  "exp": 1794700800, "iat": 1794697200, "jti": "c1d9e7" }