JSON Web Token (JWT) Security: Algorithm Confusion & Hardening

JSON Web Tokens (JWT) (RFC 7519) have become the ubiquitous standard for stateless authentication in modern distributed web architectures and microservices. When a user logs in, the authentication server issues a cryptographically signed compact string containing user claims. However, widespread developer misunderstandings regarding token signing versus encryption have led to severe enterprise account takeover vulnerabilities.

Anatomy of a JWT: Base64URL Encoding

A JWT consists of three distinct components separated by periods: Header.Payload.Signature

JSON Web Token JWT Architecture and Attack Vectors Diagram

Figure 29.1: Anatomy of a JSON Web Token and Critical Exploitation Vectors

Vital Rule: A JWT is Signed, NOT Encrypted!

A standard JWT uses JWS (JSON Web Signature). The Header and Payload are simply Base64URL-encoded JSON. Anyone who intercepts the token can decode and read all contents in cleartext! Never place sensitive secrets, credit card numbers, or passwords inside a JWT payload.

Top JWT Attack Vectors Dissected

1. The Infamous Algorithm "none" Exploit

The JWT specification permits unsecured tokens with "alg": "none" (used historically for testing). In vulnerable libraries, if an attacker changes the header algorithm to "none" and removes the signature portion (keeping the trailing period Header.Payload.), the server validates the token without verifying any signature at all, granting instant admin access!

2. Algorithm Confusion: Asymmetric (RS256) vs. Symmetric (HS256)

In an asymmetric setup (RS256), the authorization server signs tokens with its private key, and backend microservices verify tokens using the public key. In an algorithm confusion attack:

Attacker obtains the server's public key (often publicly hosted at /.well-known/jwks.json).
Attacker tampers with their token payload: {"role": "admin"}.
Attacker changes the header algorithm from RS256 to HS256 (symmetric HMAC).
Attacker signs the token using the public key string as the HMAC secret key!
If the vulnerable backend expects RS256 but blindly trusts the token's header alg, it runs HMAC-SHA256 using its public key—and the signature matches!

Where to Store JWTs: Cookies vs. LocalStorage

Storage Location	Vulnerability to XSS	Vulnerability to CSRF	Recommended Architecture
`localStorage` / `sessionStorage`	100% VULNERABLE! Any XSS bug executes `localStorage.getItem('token')` and steals the session.	Immune to CSRF.	NOT RECOMMENDED for sensitive session tokens.
`HttpOnly; Secure; SameSite=Strict` Cookie	100% IMMUNE to XSS token theft! JavaScript cannot read the cookie.	Protected by `SameSite=Strict` and anti-CSRF headers.	GOLD STANDARD! Protects user sessions from client-side script theft.

Secure JWT Verification in Node.js

const jwt = require('jsonwebtoken');

function verifyToken(token, publicKey) {
  // STRICTLY PIN the expected algorithm to defeat algorithm confusion!
  return jwt.verify(token, publicKey, {
    algorithms: ['RS256'], // Whitelist ONLY RS256! Rejects 'none' and 'HS256'
    issuer: 'https://auth.veewom.com',
    maxAge: '15m'          // Enforce short token lifespan
  });
}

Frequently Asked Questions (FAQ) - Student & Interview Review

Q1. How do you invalidate a stateless JWT before its expiration date?

Because JWTs are stateless, you cannot 'delete' an issued token on the client. To invalidate compromised tokens, maintain a fast Redis-backed token revocation denylist (recording revoked jti token IDs), or use short-lived 15-minute access tokens paired with revocable refresh tokens.

Q2. What is JWE (JSON Web Encryption)?

While JWS only signs data (leaving it readable in Base64), JWE encrypts the payload using symmetric ciphers (AES-GCM), guaranteeing that only the recipient holding the decryption key can view the payload contents.