Sessions vs JWT: Stateful vs Stateless Login

Both are ways to remember who is logged in. This is called authentication (proving who you are). A server must remember it because HTTP is stateless: each request arrives on its own, with no memory of the one before. "Sessions or JWT?" is rarely about which one is better. The real questions are: who holds the data, how fast you must be able to say "this user is logged out now", and what happens when a credential leaks. This lesson gives you the words and a simple rule to decide.

The two models

Server-side session (stateful)

A session is a record, kept on the server, that says "this visitor is logged in as user 42". "Stateful" means the server remembers things about each user. Think of a cloakroom: you hand in your coat and get a numbered ticket. The ticket is just a number. The coat stays in the cloakroom.

1. The user logs in with a password.
2. The server creates a session record (user ID, roles, created time, expiry time). It keeps the record in a store, such as Redis (a very fast in-memory database) or a database table.
3. The server sends back a random, unguessable session ID in a cookie (a small piece of text that the browser saves and sends back on every later request).
4. On every request, the browser sends the cookie. The server looks up the record and knows who the user is.

Browser ──Cookie: sid=9f3a…──▶ Server ──lookup sid──▶ Redis { userId: 42, role: "admin" }

The cookie holds no information about the user. It is only a key. If you delete the record, the key stops working at once.

JSON Web Token (stateless)

A JSON Web Token (JWT, said "jot") is a compact piece of text that holds a few facts about the user, such as the user ID, and is signed by the server. A signature is a value made from the data and a secret key. If anyone changes the data, the signature no longer matches. "Stateless" means the server keeps no record. The token itself carries the information. Think of a signed concert wristband: the guard can see it is real just by looking at it. The guard does not need to call the box office.

1. The user logs in.
2. The server builds a claims object (sub, exp, role and so on). A claim is one named fact in the token, such as the user ID. The server signs the object with a secret or a private key (explained below), and sends back the token.
3. The client sends the token on each request (in a header or a cookie). A common way is the Authorization: Bearer <token> header. "Bearer" means "whoever holds (bears) this token is allowed in".
4. The server checks the signature and the claims. It does not need a database lookup. The token itself carries the identity.

Browser ──Authorization: Bearer eyJhbGciOi…──▶ Server ──verify signature──▶ { sub: 42, role: "admin" }

What a JWT actually is

A JWT is three base64url strings joined by dots. (Base64url is a way to write any data using only letters, digits, - and _. It is only an encoding, not encryption, so it hides nothing.)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiI0MiIsInJvbGUiOiJhZG1pbiIsImlzcyI6Imh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbSIsImF1ZCI6Im15LWFwaSIsImlhdCI6MTc0OTk5NjQwMCwiZXhwIjoxNzUwMDAwMDAwfQ . <signature>  (part 1: header)  (part 2: payload, the claims)  (part 3: signature)

The header says which algorithm signed the token. The payload holds the claims. The signature is the proof. Decoded:

{ "alg": "RS256", "typ": "JWT" }{ "sub": "42", "role": "admin", "iss": "https://auth.example.com", "aud": "my-api", "iat": 1749996400, "exp": 1750000000 }

Registered claims you must understand

Registered claims are claim names that the JWT standard (RFC 7519) defines, so every library understands them. Unix seconds means the number of seconds since 1 January 1970 UTC.

Signing algorithms

A signing algorithm is the math recipe used to make and check the signature. A key is a secret value (or one half of a key pair) that the recipe needs. The two kinds differ in one line: a symmetric key is one secret that both signs and checks; an asymmetric pair has a private key that signs and a public key that checks.

JWT attacks interviewers expect you to name

• alg: none: the header can say "alg": "none", which means "no signature". Some simple libraries accepted such tokens. Always set the allowed algorithms when you verify.
• Algorithm confusion: RS256 uses a key pair and HS256 uses one shared secret. An attacker changes RS256 to HS256 and signs with the public key (which everyone can get). A library that trusts the algorithm in the token header will accept it. The fix is the same: fix the expected algorithm for each key.
• Weak HS256 secrets can be guessed offline by trying many values (this is called brute force). Use long random secrets (32 or more random bytes) or asymmetric keys.
• Using decode instead of verify. Decoding only reads the payload. It does not check the signature. Verifying checks the signature and the claims.
• Not checking exp, aud and iss. A valid signature for the wrong audience is still wrong.
• kid header injection: kid (key ID) is a header that says which key signed the token. If you use it to pick a file or run a database query, an attacker can put harmful text in it. Treat it as untrusted input.

// Verify with explicit expectations (jose library)import { jwtVerify, createRemoteJWKSet } from "jose";const jwks = createRemoteJWKSet(new URL("https://auth.example.com/.well-known/jwks.json"));export async function verifyAccessToken(token: string) {  const { payload } = await jwtVerify(token, jwks, {    issuer: "https://auth.example.com",    audience: "my-api",    algorithms: ["RS256"], // pin it  });  return payload; // exp is checked automatically}

Head-to-head comparison

Making JWTs workable: short access tokens plus refresh tokens

You cannot easily take a JWT back. So you make it expire quickly. Then you give the user a second, longer-lived credential that can get new tokens. A credential is anything that proves who you are. An access token is the short-lived token that your API accepts. A refresh token is the long-lived token that is used only to get a new access token.

Refresh token rotation: each time a refresh token is used, you issue a new one and cancel the old one. If someone shows the old token again, it was stolen. Then you revoke the whole token family and force a new login. A quiet theft now becomes something you can detect.

Login ─▶ access (10 min) + refresh R1...Access expires ─▶ send R1 ─▶ new access + refresh R2   (R1 now invalid)Attacker replays R1 ─▶ reuse detected ─▶ revoke R2 and the family ─▶ everyone re-logs in

Notice what this really is. Rotation means replacing a secret with a new one on a schedule or on every use. The refresh token works like a server-side session. Many "stateless" systems quietly bring state back exactly where they need control.

How to log a user out when you use JWTs

You cannot "delete" a token that is already in someone's hand. These are the practical options:

1. Delete it on the client and revoke the refresh token on the server. The access token still works until its short expiry. This is often fine.
2. Deny list (a list of token IDs that are no longer accepted) by jti in Redis, with a TTL (time to live, the time after which the entry deletes itself) equal to the token's remaining life. Now you do a lookup on every request. That is the state you wanted to avoid.
3. Token version: store a tokenVersion on the user. Put it in the token. When you verify, compare it with the stored value. Adding 1 to it makes every token of that user invalid. This needs one cached lookup.
4. Use sessions for that part of the system.

Choosing: a decision rule

• First-party web app (Next.js with its own backend), one domain family, and you need instant logout and permission changes: use server sessions in an HttpOnly cookie. This is simpler and safer by default. Libraries such as Auth.js (a login library for Next.js, used in its database-session mode) or iron-session (a library that keeps the session in an encrypted cookie) fit here.
• Public API, mobile clients, third-party integrations, or microservices that check a token from a central auth service: use short-lived JWT access tokens (signed with asymmetric keys) plus rotating refresh tokens. A microservice is one small service in a system made of many small services.
• Both: a common pattern is a session cookie in the browser. It talks to a backend-for-frontend (a server you own that sits between the browser and other APIs). This server holds the tokens and calls other APIs for the user (Lesson 03).

Common mistakes

1. Choosing JWT because it sounds "modern" or "scalable" for a single-domain web app. Sessions would be simpler and safer.
2. Long-lived access tokens (days or weeks) with no way to revoke them.
3. Putting sensitive data in the payload. People forget that anyone can read it.
4. Skipping aud and iss checks, or accepting any alg that the token names.
5. Storing the token in localStorage (Lesson 03).
6. Putting roles in the token and trusting them for too long. A demoted admin keeps admin powers until the token expires.
7. Sequential or guessable session IDs. Session IDs must come from a cryptographically secure random generator with plenty of entropy (randomness). OWASP (the Open Worldwide Application Security Project) recommends at least 64 bits.

Interview questions

Key takeaways

• A session is an opaque key (it means nothing by itself) to data on the server. A JWT is signed data that the client carries.
• JWTs are readable and not encrypted. Check the signature, exp, iss and aud, with a fixed algorithm.
• The price of stateless checking is hard revocation. Reduce the pain with short access tokens, rotating refresh tokens and token versions.
• For a first-party web app, sessions are usually the simpler and safer default. JWTs work well across services and for third-party access.

What's next

Lesson 03: Where Do Tokens Live? Now you know what the credential is. Next: where the browser should keep it, and how that choice trades XSS risk against CSRF risk.