Session-based versus token-based authentication

WHAT THIS TESTS Whether you grasp the statefulness trade-off and can apply it to horizontal scaling and microservices rather than reciting definitions.

A GOOD ANSWER COVERS In session-based auth the server creates a session record and hands the client an opaque session id, usually in an httpOnly cookie. Every request, the server looks up that id in its store to find the user. Pros: instant revocation (delete the record), small cookie, server controls everything. Cons: requires a shared session store like Redis when you run multiple instances, adding a lookup per request. In token-based auth the server issues a signed JWT containing the claims; any service can verify it locally with the key and trust the contents without a central lookup. Pros: stateless, scales horizontally, ideal across microservices and third-party APIs. Cons: hard to revoke before expiry, larger payload sent every request, and refresh-token rotation reintroduces some state.

COMMON WRONG ANSWERS Declaring JWT strictly superior, ignoring the revocation problem, or claiming sessions cannot scale at all.

LIKELY FOLLOW-UPS How to revoke JWTs, why a shared store is needed for sticky-less load balancing, refresh tokens, and token size impact on requests.

ONE CONCRETE EXAMPLE With five Express instances behind a load balancer, sessions require Redis so any instance can find the session; with JWTs each instance verifies the signature independently with the shared key, so no shared store is needed, but logging a user out everywhere immediately requires an extra denylist that partly undoes the statelessness.