JWT Structure
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header identifies the signing algorithm. The payload contains claims about the user. The signature verifies the token hasn't been tampered with.
The Claims Payload
Standard claims include 'iss' (issuer), 'sub' (subject), 'exp' (expiration time), 'iat' (issued at). The payload is Base64URL-encoded but not encrypted — anyone can decode and read it. Never put sensitive data in JWT payloads unless using JWE.
Verification and Security
The server verifies a JWT by recomputing the signature using the same secret key. Critical security rules: always validate expiration, always verify the algorithm matches your expectation, and use asymmetric keys for systems with multiple token consumers.
JWTs vs Sessions
Traditional session tokens require server-side state and a database lookup per request. JWTs are self-contained — all claims are in the token. This makes JWTs better for stateless, horizontally scaled services, while traditional sessions are easier to invalidate immediately.
JWTs are powerful for stateless authentication but have important security nuances. Validate signatures rigorously, check expiration, use strong algorithms, and never store sensitive data in unencrypted payloads.