JWT structure and how the signature works

WHAT THIS TESTS Whether you understand that a JWT provides integrity and authenticity but not confidentiality, and can describe its exact structure.

A GOOD ANSWER COVERS A JWT is three base64url-encoded segments joined by dots: header.payload.signature. The header declares the token type and the signing algorithm, for example HS256 or RS256. The payload carries claims, standard ones like sub (subject), iat (issued at), and exp (expiry), plus custom data. The signature is produced by hashing the encoded header and payload together with a secret (HMAC) or a private key (RSA/ECDSA). On each request the server recomputes the signature over the received header and payload and compares; if anyone altered a claim, the recomputed signature will not match, so the token is rejected. Crucially the payload is only encoded, not encrypted, so anyone can read it.

COMMON WRONG ANSWERS Claiming the payload is encrypted or safe for secrets, thinking the signature encrypts the data, or asserting that base64url provides any security.

LIKELY FOLLOW-UPS HMAC versus asymmetric signing, why you must never put passwords in the payload, the alg none attack, and how expiry is enforced.

ONE CONCRETE EXAMPLE Given a token where the payload claims role user, an attacker decodes it, changes role to admin, and re-encodes it. Because they lack the signing secret, the signature no longer matches the tampered payload, so jwt.verify throws and the request is denied. This is exactly the integrity guarantee the signature provides.