Inside JSON Web Tokens (JWT): Header, Payload, Cryptographic Signatures, and Security Best Practices

Stateless Architecture: Why JWTs Dominates Modern APIs#

In traditional stateful session authentication, servers generate a random session ID, store it in Redis or a relational database, and transmit it via a cookie. As distributed applications scale to dozens of microservices, checking the session store on every API call becomes an expensive infrastructure bottleneck.

JWTs solve this by embedding the user’s identity (e.g. user ID, email, role permissions) directly inside the token payload itself. The server cryptographically validates the token’s signature using its secret or public key without making any external database queries.

The Three Components: Header, Payload, and Signature#

A JWT is represented as three distinct Base64URL-encoded strings concatenated by period (`.`) delimiters:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJ1c2VyIjoiQWFrYXNoIiwiYWRtaW4iOnRydWUsImV4cCI6MTc4Nzc4NjgwMH0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

1. Header (Red):    Algorithm & token type metadata
2. Payload (Purple): Subject claims, roles, and expiration timestamp
3. Signature (Blue): Cryptographic hash verifying header + payload integrity

Symmetric HS256 vs Asymmetric RS256 / ES256 Signing#

JWT signatures are generated using either symmetric or asymmetric cryptographic algorithms:

• HS256 (HMAC with SHA-256): Uses a single shared secret key for both signing and verifying tokens. Ideal for monolithic applications where the issuer and consumer are the exact same server.
• RS256 (RSA Signature with SHA-256): Uses an asymmetric private key to sign the token and a publicly distributed public key to verify it. Standard in microservice architectures and OAuth/Auth0 providers.
• ES256 (ECDSA with P-256): Uses elliptic curve cryptography to deliver the same cryptographic strength as RS256 with significantly smaller token sizes and faster verification speeds.

Standard Registered Claims (iss, sub, exp, nbf, iat)#

RFC 7519 defines standard reserved claim keys that every production token should implement:

Critical Security Vulnerabilities: "alg: none" & Key Confusion#

Flawed JWT library implementations have led to severe historic security exploits:

• The "alg: none" Attack: Some early libraries accepted tokens where the algorithm header was set to `"none"`, allowing attackers to forge arbitrary admin claims with no signature.
• Key Confusion Attack: Tricking an RS256 verification server into verifying with HS256 using the publicly available RSA public key as the HMAC shared secret.

Token Storage Best Practices: HttpOnly Cookies vs LocalStorage#

Storing authentication JWTs in browser `localStorage` leaves tokens vulnerable to Cross-Site Scripting (XSS) attacks. If malicious JavaScript executes on your page, it can read `localStorage.getItem("token")` and exfiltrate credentials.

For web applications, store access and refresh tokens in `HttpOnly`, `Secure`, `SameSite=Strict` cookies, preventing JavaScript code from accessing the token directly.