04 / 06

Are Cookies Better Than JWT?

To start with, you can create session-based cookies, which automatically expire after the user session is closed, or you can easily set an expiration time for a cookie, which gives more control over session invalidation. You can also use HttpOnly cookies to prevent JavaScript from accessing the cookie information.

  1. 1

    However, it's important to note that cookies come with their own flaws. Specifically, as the cookie data is stored on the server and the cookie identifier is stored on the client, they're not entirely stateless like JWTs. This means that the server needs to store and retrieve the cookie data for each request, which would be additional overhead to the authentication process and slow down the application's performance, especially if the number of concurrent users increases.

  2. 2

    They're also not ideal for non-browser-based applications, such as mobile and desktop applications. Additionally, cookies can be more vulnerable to certain attacks, such as cross-site scripting (XSS) and cross-site request forgery (CSRF).

Difficulty: 6/10
Topics: Session Management, Web Security, Authentication Architecture

Scenario Questions

0-2 years experience
  1. 1

    We are building a simple React SPA that talks to a Node.js backend. You need to store the user's login session. If you store a JWT in localStorage versus an HttpOnly cookie, what actually happens if an attacker manages to inject a malicious script (XSS) into our site?

  2. 2

    Imagine we have a mobile app and a web app both talking to the same API. The web team wants to use cookies for authentication, but the mobile team wants to pass a token in the Authorization header. How would you set up the backend to support both, and what's the main difference in how the backend validates these requests?

2-5 years experience
  1. 1

    We recently migrated our frontend to a separate domain (e.g., my-app-client.com talking to api.my-app-backend.com). Suddenly, users are complaining they get logged out immediately on Chrome, but it works fine on Safari or older browsers. What's likely going on with our cookie configuration, and how would switching to a JWT in the Authorization header bypass or solve this?

  2. 2

    Our security team flagged that our JWTs are valid for 24 hours, and we have no way to log a user out globally if their account is compromised. If we want to keep our stateless JWT architecture but need to support instant logout/revocation, how would you design a hybrid solution using Redis?

5-8 years experience
  1. 1

    We are designing the authentication layer for a high-throughput microservices architecture with 50+ downstream services. If we use traditional session cookies, our gateway has to hit a central Redis session store on every single request. If we switch to stateless JWTs, we save those DB lookups, but we lose the ability to instantly ban users or change permissions. Walk me through how you would design a hybrid token-revocation or blocklist system that scales to 100k requests per second.

  2. 2

    We have a multi-tenant SaaS platform where enterprise customers want to embed our dashboard inside their own portals via iframes. Our current auth relies on standard session cookies. Why is this going to fail in modern browsers, and how would you redesign the authentication flow (potentially using JWTs or postMessage) to support secure third-party iframe embedding?

8+ years experience
  1. 1

    Our company is planning to merge three legacy platforms—one uses ASP.NET stateful session cookies, one uses a custom OAuth2/JWT gateway, and the third uses basic auth headers. We need to establish a single unified Identity Provider (IdP) and SSO experience across all three without forcing a complete rewrite of their backends on day one. How would you architect the migration path, and what are the security and operational trade-offs of forcing a cookie-based vs. token-based standard at the API gateway level?

  2. 2

    As we move towards a zero-trust architecture across our global infrastructure, we are debating between short-lived JWTs (cryptographically signed) and centralized, stateful opaque tokens. Given our strict compliance requirements (HIPAA/GDPR) regarding immediate access revocation and audit logging, how would you evaluate these two approaches, and what organizational overhead (key rotation, latency, cross-region replication) should we prepare for?

Follow-up Questions

  • If we store a JWT in an HttpOnly cookie, how do we protect against CSRF?
  • How would you implement immediate token revocation for a compromised JWT without making the database a bottleneck?
  • What happens to our cookie-based auth if we migrate our frontend to a completely different domain?