Claims and cryptographic wrappers differ

A JWT Claims Set is a JSON name–value object. JWS signs or MACs it; JWE encrypts it, and nesting is possible. Compact forms separate URL-safe encoded parts with dots, with the number depending on the wrapper rather than one universal three-part shape.

Base64url is encoding, not secrecy. A signed payload is ordinarily readable by a token holder, and a signature does not conceal fields. Confidentiality requires appropriate encryption and transport protection.

References: [1]

Profiles constrain generic claims

Issuer, subject and audience identify parties, while exp and nbf express expiration and not-before conditions. RFC 7519 does not require every registered claim in every JWT; an application profile defines its required fields and interpretation.

Consequently, one well-formed JWT is not suitable everywhere. OpenID Connect ID Tokens, access tokens and security-event tokens follow different profiles. Application fields do not authorize operations independently of those contracts.

References: [1] [2] [3]

Parsing is not acceptance

A verifier checks cryptographic operations using application-allowed algorithms and trusted keys, then issuer, subject, audience and applicable time conditions. RFC 8725 restricts algorithms through caller policy instead of letting an untrusted header choose arbitrarily.

An issuer can produce several JWT kinds whose validation rules must reject substitution. Types, required claims, audiences or keys can distinguish them. A correct signature alone does not make a token intended for another client or purpose acceptable.

References: [2]