02 / 06

How does it differ from using sessions?

  1. 1

    In a typical session flow, the browser sends a cookie containing a token, which is then matched at the server to some data which the server makes use of to authenticate the user.

  2. 2

    In a JWT flow, the token itself contains the data. The server decodes the token to authenticate the user. No data is stored on the server.

Difficulty: 6/10
Topics: Stateless vs Stateful, Token Revocation, Security Tradeoffs

Scenario Questions

0-2 years experience
  1. 1

    We have a simple React app and a Node backend. If we switch from standard cookie-based sessions to JWTs, where should we store the JWT on the client side to prevent XSS, and how does the backend verify it on each request?

  2. 2

    Imagine a user logs out of our app, but we are using stateless JWTs. If an attacker intercepted that JWT before logout, can they still use it? How would you handle a logout event in this setup?

2-5 years experience
  1. 1

    Our team recently migrated from Redis-backed sessions to stateless JWTs to save on database roundtrips. However, our customer support team is complaining that they can no longer force-reset a compromised user's session immediately. How would you resolve this without completely reverting back to stateful sessions?

  2. 2

    We are building a mobile app and a web app that share the same backend. The web app is vulnerable to CSRF if we use cookies, but storing JWTs in localStorage exposes us to XSS. How would you design the token storage and transmission strategy for both platforms to balance these risks?

5-8 years experience
  1. 1

    We are scaling our microservices architecture to handle 100k requests per second. If we use stateless JWTs, we avoid hitting a central session store, but our JWTs have grown to 4KB due to user permissions metadata, causing significant network overhead. How would you redesign our authentication and authorization flow to address this?

  2. 2

    We need to implement a 'blocklist' or immediate revocation mechanism for compromised accounts in a high-throughput system using JWTs. How would you architect this so we don't end up re-introducing the exact same database bottleneck we tried to avoid by moving away from traditional sessions?

8+ years experience
  1. 1

    We are planning to migrate a legacy monolithic application with 10 million active users from a sticky-session, server-side state model to a decentralized microservices architecture. What is your strategy for migrating the authentication state without forcing all active users to log out, and how do you align the security teams on the trade-offs of stateless tokens?

  2. 2

    Our enterprise SaaS platform needs to support both standard user sessions and third-party API integrations. Some engineering teams are pushing for a unified JWT-only architecture, while others want to keep traditional sessions for the web app and API keys for integrations. How do you evaluate these architectural directions, and what standard would you establish for the organization?

Follow-up Questions

  • If we use a short-lived JWT with a sliding-window refresh token, where should the refresh token be stored securely?
  • How does the payload size of a JWT affect network performance at scale compared to a simple 32-character session ID?
  • If a user changes their password, how do we invalidate all active JWTs without maintaining a stateful database of blacklisted tokens?