JSON Web Tokens: Anatomy, Cryptographic Signature, and Client Boundary
RFC 7519 defines JSON Web Tokens (JWT) as a compact, URL-safe means of transferring verifiable claims between parties. Decoding a token client-side is useful for inspecting expiration (exp) and scopes, but does not substitute server-side cryptographic verification.
1. The Tripartite Format
A JWT comprises three Base64URL-encoded parts separated by dots: Header.Payload.Signature.
The Header identifies the hashing algorithm (alg, e.g., HS256, RS256). The Payload carries the claims (sub, exp, iat, iss). The Signature protects against tampering.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoiQWxpY2UiLCJleHAiOjE3OTAwMDAwMDB9
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c2. The 'None' Algorithm Vulnerability
Historical security vulnerabilities arose when servers accepted tokens where the algorithm header was set to 'none' without checking signature validity. Strict decoders reject tokens with missing signatures.
Summary & Best Practices
Client-side JWT inspection provides immediate visibility into session claims while strictly treating payload values as unverified until confirmed by a public-key cryptographic check.