Understanding JSON Web Token (JWT), JWS, and JWE: Structure, Claims, and Encryption

JWT (JSON Web Token) is a compact, URL‑safe string used to securely transmit claims between a client and a server. It consists of three Base64URL‑encoded parts: header, payload, and signature, separated by dots.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

The header declares the token type (JWT) and the signing algorithm (e.g., HS256). Optional fields such as jti (JWT ID) and cty (content type) may also appear.

The payload carries registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims defined by standards, and private claims defined by the application. Sensitive data should never be placed in the payload unless it is encrypted.

JWT solves authentication, authorization, federated identity, stateless sessions, and client‑side secrets.

JWS (JSON Web Signature)

JWS adds a digital signature to a JWT, ensuring integrity and authenticity. The signature is generated from the Base64URL‑encoded header and payload using a secret (HMAC) or a private key (RSA/ECDSA).

RSASSA || ECDSA || HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Supported signature algorithms include symmetric HMAC (HS256/HS384/HS512) and asymmetric RSA (RS256/RS384/RS512) or ECDSA (ES256/ES384/ES512).

JWE (JSON Web Encryption)

JWE encrypts the JWT payload to protect confidentiality. A JWE token has five parts: protected header, encrypted key, initialization vector, ciphertext, and authentication tag.

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.UGhIOguC7Iu... (five dot‑separated segments)

The encryption process involves generating a content encryption key (CEK), encrypting the CEK with the key management algorithm (alg), optionally compressing the plaintext, and then encrypting the data with the CEK using the enc algorithm.

JWE header fields include alg (key encryption algorithm), enc (content encryption algorithm), optional zip, and other JOSE parameters such as jku, kid, x5u, etc.

Practical Usage

In a typical web application, after a successful login the server issues a JWT. The client stores the token (e.g., in localStorage or a secure HttpOnly cookie) and sends it in the Authorization: Bearer <token> header for protected requests. The server validates the signature (and optionally decrypts the payload) to authorize the request.

Choosing between HMAC and RSA/ECDSA depends on the scenario: HMAC is fast and suitable for single‑service or single‑signer use‑cases, while RSA/ECDSA enables one‑to‑many verification with public keys.

Additional promotional content from the original source has been omitted for clarity.