Session-Based vs Token-Based (JWT) Authentication

In traditional Session-Based Authentication, state is maintained on the server. The workflow proceeds as follows:

1. Login: The user submits credentials to the authentication server.
2. Session Creation: The server validates credentials, generates a cryptographically random 128-bit session ID (e.g., s_8f4b2e91a0c74...), serializes the user's session data (userId, role, ip, createdAt), and saves it into an in-memory datastore (e.g., Redis or Memcached) with a Time-To-Live (TTL) of e.g., 24 hours.
3. Cookie Delivery: The server returns the session ID to the client inside a secure HTTP cookie configured with HttpOnly, Secure, and SameSite=Lax.
4. Subsequent Requests: The browser automatically attaches the cookie to every request. Any backend server queries Redis (O(1) lookup, typically < 1ms) to retrieve the session state.

Sizing and Memory Calculations:

Consider an enterprise application with 10 million daily active concurrent sessions:

• Size per session entry in Redis (user ID, permissions, IP, metadata): ≈ 1 KB
• Total active RAM required: 10{,}000{,}000 × 1 KB = 10 GB
• Adding Redis replication factor (1 primary + 2 replicas) and memory overhead: ≈ 35 GB RAM.
• At 100,000 requests/sec, the Redis cluster must handle 100k QPS of session lookups, requiring clustered Redis with pipelining.

In Token-Based Authentication, the server does not store session state. Instead, state is encoded directly inside a cryptographically signed payload called a JSON Web Token (JWT):

1. Login: The user submits credentials.
2. Token Issuance: The authentication server signs a structured JSON payload containing user claims using its Private Key (asymmetric RSA/ECDSA) or a shared secret (HMAC):

   json
   Copy
   {
     "sub": "usr_48291",
     "name": "Alice Smith",
     "role": "editor",
     "iat": 1714000000,
     "exp": 1714000900
   }

3. Delivery: The token string is returned in the JSON response body.
4. Decentralized Verification: On subsequent requests, the client transmits the token via the Authorization: Bearer <token> HTTP header.
5. Zero Database Lookups: Any microservice across different data centers can independently verify the token's validity in under 0.05ms using the public key cached in memory, eliminating database bottlenecks.

The fundamental trade-off between sessions and JWTs revolves around state vs. revocation:

The JWT Revocation Problem:

Because a JWT is self-contained and validated strictly through cryptography without consulting a database, a JWT cannot be revoked before its expiration timestamp (exp).

• If an employee is fired, an attacker steals a token, or a user changes their password, the active JWT remains valid until exp runs out.
• The Anti-Pattern (JWT Blacklist in Redis): If you create a distributed Redis blacklist to check whether a JWT has been revoked on every request, you have eliminated the stateless benefit of JWTs while keeping the large payload overhead of tokens!

Comparative Breakdown:

To achieve both horizontal scalability across microservices and rapid security revocation, modern systems (OAuth 2.0 / OIDC) utilize a Hybrid Token Architecture:

code
Copy
[ Client App ]
      │
      ├── 1. Uses Short-Lived Access Token (JWT - 15 min TTL) ──► [ Microservices ] (Stateless!)
      │      (No DB lookups; fast local public key verification)
      │
      └── 2. When Expired: Presents Long-Lived Refresh Token ──► [ Auth Server / Redis ]
             (Opaque 7-day token; stateful lookup & rotation)

How the Hybrid Architecture Works:

1. Access Token (Stateless JWT):
   • Lifespan: 5 to 15 minutes.
   • Carried in API requests to downstream microservices.
   • Microservices verify tokens purely via cached public keys (JWKS).
   • Maximum compromise exposure is limited to 15 minutes.
2. Refresh Token (Stateful & Opaque):
   • Lifespan: 7 to 30 days.
   • Stored securely in an HttpOnly, SameSite=Strict cookie or encrypted mobile keychain.
   • Stored in the central database/Redis with user metadata.
   • Refresh Token Rotation (RTR): Every time the client uses a refresh token to obtain a new 15-minute access token, the auth server invalidates the old refresh token and issues a brand-new one. If an old refresh token is reused, the auth server flags a token theft breach and immediately revokes the entire token family, forcing a full password re-login.