1. Stateless Session Management: Why We Use Tokens

1.1 The Stateful session Bottleneck

In a stateful session model, the server must keep a record of every active session. If you have 10 million active users, your database or Redis cache must store 10 million session keys. Furthermore, every single API request requires a database look-up to verify the session status. In a microservices architecture where a single user action might trigger requests across 20 separate backend services, routing each request through a central session lookup creates a massive bottleneck. This bottleneck limits throughput and increases latency across your application stack.

Stateless authentication solves this by moving session storage from the server to the client. The server generates a token containing the user's metadata (user ID, roles, expiration time) and signs it using a private key. The browser stores this token (usually in local storage or a secure cookie) and attaches it to the Authorization header of every API request. The backend microservices can verify the token's signature locally without querying a central session database. This decouples authentication from database scale, allowing microservices to scale independently.

1.2 Authentication vs Authorization

It is critical to distinguish between authentication (proving who you are) and authorization (proving what you are allowed to do). JWTs are primarily designed for **authorization**. When a user logs in (authentication), the server returns a JWT. For all subsequent requests, the microservices inspect the claims (roles, permissions) inside the JWT to decide if the user is authorized to access the requested resource. This decentralized authorization is what makes microservice APIs highly efficient.

Common Misconception — JWTs Encrypt Your Data: A common misconception is that JWTs are encrypted and secure from public eyes. In reality, standard JWTs are **signed, not encrypted**. The header and payload are simply encoded using base64url, which is a reversible encoding, not encryption. Anyone who intercepts the token can read your user IDs, roles, and emails. Never store sensitive, private data (like passwords, social security numbers, or API keys) inside a standard JWT payload.

2. The Anatomy of a JWT: Header, Payload, and Signature

2.1 The Three-Part Token Structure

A JSON Web Token consists of three distinct parts separated by dots (.): (1) **Header**: contains metadata about the token, such as the signing algorithm used (e.g. HS256, RS256) and the token type (JWT). (2) **Payload**: contains the **claims** — the statement of user metadata (e.g., sub for subject/user ID, exp for expiration timestamp, and custom roles). (3) **Signature**: the cryptographic hash generated by combining the header, payload, and a secret key, protecting the token from tampering. We can represent this structure as:

2.2 Base64url Encoding

To make tokens safe to transmit over HTTP headers and URLs, each section is encoded using **base64url**. This encoding is a variant of standard base64 that replaces character + with -, character / with _, and removes trailing padding equals signs (=). This prevents URL parsers from misinterpreting the token as path parameters or query variables.

3. Signing Algorithms: Symmetric HS256 vs Asymmetric RS256

3.1 HMAC-SHA256 (HS256)

The **HS256** algorithm uses a symmetric key model. The same secret key is used to both *generate* the signature (sign) and *validate* the signature (verify). It is highly efficient and simple to configure, making it the default choice for single, unified applications. However, in a distributed microservices environment, using HS256 requires distributing the shared secret key to every microservice that needs to validate tokens. If a single microservice is compromised, the attacker steals the secret key and can generate valid, forged admin tokens for the entire system.

3.2 RSA-SHA256 (RS256)

The **RS256** algorithm uses an asymmetric key model (public/private key pair). The authentication server uses a private key (kept secret) to sign the token. All other microservices use the matching public key (shared openly) to verify the signature. If a microservice is compromised, the attacker only gets the public key, which cannot be used to forge new signatures. This makes RS256 significantly more secure and scalable for multi-tenant, cloud-native deployments, as the private key remains locked on a single secure authorization node.

4. The Signature Verification Math

4.1 Signature Generation and Comparison

To verify a token's signature, the receiver splits the token into its three parts using the dot separator. It extracts the raw header string and payload string. To check for tampering, the receiver recalculates the signature using the algorithm declared in the header and compares it to the signature attached to the token. In the symmetric HS256 model, this recalculation can be formalized as:

If the computed signature matches the token signature exactly, the database knows that the header and payload have not been altered in transit, and that the token was generated by a party that holds the secret key.

Mermaid Diagram: The asymmetric token lifecycle under RS256 signing.

5. The Alg None Vulnerability: Bypassing Signature Verification

5.1 The Blind Trust Exploit

One of the most famous security exploits in early JWT implementations was the **"alg none"** vulnerability. The JWT specification allows for unsigned tokens by setting the algorithm header field to none: {"alg": "none", "typ": "JWT"}. This was intended for debugging or internal communication over secure channels. However, early validation libraries were designed to read the header first, see "alg": "none", and skip signature verification entirely, treating the token as valid.

An attacker could exploit this by taking a valid user token, changing the payload to {"user": "admin"}, changing the algorithm header to none, removing the signature part (but keeping the trailing dot: header.payload.), and sending it to the server. The server, trusting the header, would parse the payload and grant admin access without checking anything. Modern JWT libraries block this by requiring developers to explicitly specify which algorithms are permitted, rejecting none by default.

6. Asymmetric Key Confusion Attack

6.1 The Public Key Signature Hack

The **Asymmetric Key Confusion Attack** occurs when a server is configured to use RS256 (asymmetric) for validation, but the validation library is tricked into treating the public key as a symmetric HS256 secret. To verify an RS256 signature, the library expects a public key. However, if the library is not strict about algorithm types, an attacker can modify the token's header from RS256 to HS256. The attacker then takes Bob's public key (which is public and easily obtainable) and uses it to sign a modified payload using HS256 (symmetric HMAC).

When the server receives this token, it parses the header: "Ah, the algorithm is HS256". It looks up the key configuration, retrieves the public key, and passes it to the HMAC function as the secret key. The server calculates the HMAC signature using the public key and compares it to the attacker's signature. Since the attacker signed the token using the same public key and HMAC-SHA256, the signatures match, and the server validates the forged token. Protect against this by forcing your validation library to only accept the specific expected algorithm (e.g. RS256) rather than reading it from the user-provided header.

6.2 Mechanics of the Confusion Attack

To understand the vulnerability, we must look at how cryptographic libraries handle keys. In asymmetric RS256, the public key is represented in a format like PEM (Privacy-Enhanced Mail):

A standard JWT library uses this public key as a string or buffer. If the algorithm is changed to HS256, the library treats this entire string buffer, including the header and footer comments, as a raw binary array of bytes acting as the HMAC shared secret. An attacker performs this attack offline by loading the public key file and executing:

When the attacker sends the forged token, the vulnerable backend executes the exact same HMAC-SHA256 function using the public key string, matching the computed signature to the forged one. This completely compromises authorization security. You can defend your system against key confusion by implementing a strict verification schema. For instance, in Node.js, always restrict the allowed algorithms array parameter:

Pitfall — Exposing Key Discovery Endpoints: Many modern federated identity platforms expose public keys at standard endpoints (e.g. /.well-known/jwks.json). While this makes key rotation simple, it also means attackers can easily download your public keys to perform offline confusion attacks. Always ensure your code enforces strict algorithm restrictions for all keys loaded from JWKS endpoints.

7. Advanced: Token Revocation and Refresh Token Rotation

7.1 Revoking the Irrevocable

The major architectural trade-off of stateless tokens is the **revocation problem**. Once a JWT is issued, it is valid until its expiration timestamp (exp) is reached. If a user logs out, closes their account, or has their device stolen, there is no built-in way to cancel the token. The server does not check a database; it simply checks the signature, meaning the stolen token remains valid. To balance safety and scale, we must implement a revocation strategy. Setting a short lifespan for the access token guarantees that even if a token is stolen, the window of vulnerability is extremely narrow and will automatically close once the expiration time passes.

The standard approach is using **Refresh Token Rotation**. We issue two tokens: a short-lived **Access Token** (valid for 10-15 minutes) and a long-lived **Refresh Token** (stored in a database and sent in a secure cookie). When the access token expires, the client sends the refresh token to the authorization server to fetch a new access token. If the refresh token is rotated (invalidated and replaced on every use), the server can detect reuse attacks (if a leaked refresh token is reused, the server invalidates the entire session family, protecting the user from ongoing extraction). Additionally, when a user logs out, we can store the access token's unique ID (jti) in a Redis cache with a Time-To-Live (TTL) matching the token's remaining lifespan, ensuring the token is blocked immediately without bloating the database long-term.

8. Advanced: JWT Side-Channel and Brute-Force Attacks

8.1 Brute-Forcing HS256 Keys

Because the signature of an HS256 token is generated using a symmetric secret, an attacker who captures a valid JWT can attempt to brute-force the secret key offline on their own hardware. Since the verification only requires hashing, tools like Hashcat can execute billions of HMAC-SHA256 calculations per second on modern GPUs. If your secret key is a weak string (e.g. my-secret-key-123), the attacker will crack it within minutes, allowing them to sign arbitrary tokens. Always generate strong, random keys (at least 256 bits long) using cryptographic entropy, and rotate them regularly.

9. Complete Express/NodeJS JWT Implementation from Scratch

9.1 Custom Token Generator and Validator

The following Node.js code implements a basic JWT library from scratch, demonstrating base64url encoding, HS256 signature generation, and verification checks manually, without third-party library dependencies:

10. Interactive: JWT Signature Verification Simulator

Select the action and click Run. Watch how the simulator encodes the token, and how the server detects and blocks tampered payloads or alg-none attempts:

Verification Latency: DB Lookup vs Local JWT Check

The chart below compares the average verification latency (in milliseconds) for 1000 sequential API requests between database-backed stateful sessions and local JWT signature checks:

12. Frequently Asked Questions