JSON Web Token (JWT)

JSON Web Token (JWT): a compact, signed way to carry claims like identity or session data between systems, defined in IETF RFC 7519.

A JSON Web Token (JWT) is a compact, URL-safe way of packaging a set of claims - statements about a user, a session or a device - as a JSON object, so they can travel between systems as a single string. It is defined by the IETF in RFC 7519, published in May 2015, and updated by RFC 8725, "JSON Web Token Best Current Practices", which adds security guidance including the algorithm-confusion pitfall described below.

A JWT is normally wrapped in a JSON Web Signature (JWS) structure, which signs the claims so a receiving party can verify they have not been altered. When the claims must stay confidential rather than merely tamper-evident, it can be wrapped in JSON Web Encryption (JWE) instead, which encrypts them so only the intended recipient can read them.

RFC 7519 defines a small set of registered claim names that recur across almost every JWT, including, among others:

• iss (issuer): who created and issued the token
• sub (subject): who or what the token is about
• aud (audience): who the token is intended for
• exp (expiration time): the moment after which the token must be rejected
• iat (issued at): when the token was created

RFC 7519 also registers a few further claims for finer control, such as nbf (not before), which delays a token's validity until a set time, and jti (JWT ID), a unique identifier used to detect replay.

This mechanism is behind the ID token in OpenID Connect (OIDC) and behind many OAuth 2.0 access tokens, and it is also the building block that SD-JWT extends to let a wallet holder disclose only some of the claims inside.

Note: a plain JWT is signed, not encrypted. Anyone who intercepts it can decode the header and payload and read the claims in full - base64url is a reversible encoding, not confidentiality protection. Only the JWE variant hides the content; a signature-only JWT protects integrity, not secrecy. A related pitfall is algorithm confusion: because the header names the signing algorithm, a verifier that blindly trusts that value can be tricked into accepting a token signed with 'none' or verified with the wrong key type. RFC 8725, "JSON Web Token Best Current Practices", addresses this directly: verifiers must fix the expected algorithm themselves rather than read it from the token.