Session-based versus token-based authentication
auth architecture trade-offs.
sessions store server-side state with a cookie id, tokens carry self-contained claims with no server store, weigh revocation versus scalability, especially across services.
What's really being asked
Whether you grasp the statefulness trade-off and can apply it to horizontal scaling and microservices rather than reciting definitions.
The full answer
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.
The mistakes people make
Declaring JWT strictly superior, ignoring the revocation problem, or claiming sessions cannot scale at all.
What usually comes next
How to revoke JWTs, why a shared store is needed for sticky-less load balancing, refresh tokens, and token size impact on requests.
A 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.
Interview question
Across five stateless Express instances behind a load balancer, what is the main operational cost of choosing session-based auth over JWTs?
- a.You need a shared session store so any instance can resolve the sessionCorrect
- b.Sessions require asymmetric keys on every node
- c.Sessions cannot work with more than one server
- d.Sessions expose the user id in the cookie
Why? this is the answer
Session state must be reachable by whichever instance handles a request, so a shared store like Redis is required. JWTs avoid that by being self-contained and locally verifiable; sessions absolutely can scale, just with shared storage.
Just read this? Test yourself on what you have been reading.
Read the original → knowledge.businesscompassllc.com
- #authentication
- #sessions
- #jwt
- #microservices
- #scalability
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on authentication — each one lists the topics its interview covers.
See open roles