JWT Tokens Explained: Security & Decoding

1. What is a JSON Web Token (JWT)?

A JWT (pronounced 'jot') is an open, IETF-standardized format (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. Because JWTs are digitally signed using either a secret key (HMAC) or a public/private key pair (RSA or ECDSA), their authenticity and claims can be cryptographically verified.

Unlike stateful session identifiers stored in centralized memory stores like Redis or relational databases, JWTs are stateless. Every request carries the necessary authorization data directly inside the token, enabling microservices to validate user identity without database round-trips.

2. The Anatomy of a JWT

A serialized JWT consists of three distinct Base64URL-encoded segments separated by periods (header.payload.signature):

Header: Specifies the cryptographic algorithm (e.g., HS256, RS256) and the token type ('JWT').

Payload: Contains standard and custom claims (e.g., sub for user ID, exp for expiration timestamp, iss for token issuer, and user role privileges). Important: The payload is Base64URL encoded, NOT encrypted. Anyone with access to the token can read every claim.

Signature: Generated by running the encoded header, encoded payload, and your server secret through the specified cryptographic hashing algorithm. If a malicious actor tampers with any claim in the payload, the signature becomes invalid.

3. Crucial Security Best Practices

Never store confidential secrets in the Payload: Passwords, payment card numbers, personal identifiable information (PII), or private API keys must never be placed inside a JWT payload because Base64URL encoding is trivial to reverse.

Enforce Short Expiration Lifetimes: Always include the 'exp' claim and configure access tokens with lifetimes between 5 and 15 minutes. Long-lived access tokens represent an ongoing security hazard if intercepted over untrusted networks.

Store Tokens in HttpOnly, Secure, SameSite Cookies: Storing JWTs in browser localStorage exposes them to Cross-Site Scripting (XSS) extraction. Storing session tokens in HttpOnly cookies prevents client-side JavaScript access.

4. Critical Attack Vectors: The Algorithm Confusion Vulnerability

One of the most dangerous vulnerabilities in naive verification setups is the Algorithm Confusion Attack. When a backend verifies RS256 (asymmetric) tokens using its public key, an attacker can modify the token header to declare HS256 (symmetric) and sign the forged token using the server's public key as the symmetric HMAC secret.

If the server verification routine does not strictly enforce the expected algorithm, it will verify the forged token using its own public key as the HMAC secret. To mitigate this vulnerability, verify tokens using strict algorithm whitelisting (e.g., algorithms: ['RS256']) and reject the insecure 'alg': 'none' header unconditionally.

5. JSON Web Key Sets (JWKS) & Dynamic Key Rotation

Production identity providers (such as Google Identity, Auth0, AWS Cognito, and Keycloak) sign tokens using asymmetric key pairs that rotate periodically. Verifying services query the provider's JWKS endpoint (typically hosted at /.well-known/jwks.json).

Each token header contains a Key ID ('kid'). The verifying service matches this kid against its cached JWKS keys to validate the RSA or ECDSA signature. Caching keys with an appropriate TTL prevents denial-of-service round-trips to identity providers on every API request.

6. Refresh Token Rotation & Family Revocation

Because access tokens are stateless, revoking them before expiration requires a centralized revocation blacklist. The industry standard architecture is Refresh Token Rotation.

Every time a client exchanges a refresh token for a new access token, the auth server invalidates the previous refresh token and issues a brand-new one tied to the same token family. If an attacker and a legitimate user attempt to redeem the same refresh token twice, the server detects token reuse, invalidates the entire token family, and forces all sessions to re-authenticate.