What is the difference between session-based auth and token-based auth?
Quick Answer
Session auth — the server creates a session, stores it server-side, and gives the client a session-id cookie; each request looks the session up. Easy to revoke, but stateful (needs a shared session store to scale). Token auth — the server issues a signed token the client sends each request; the server validates it without a lookup. Stateless and scales freely, but hard to revoke before expiry.
With session auth, when you log in the server creates a session record, keeps it in memory or Redis, and sends you a cookie with just the session id. Every request, it looks that id up. It's trivial to revoke — delete the session — but it's stateful, so scaling out needs a shared session store. With token auth, the server hands you a signed token containing your claims, and every request it just validates the signature and expiry, no lookup. That's stateless and scales effortlessly, but you can't easily kill a token before it expires, so you keep access tokens short-lived and use refresh tokens. Server-rendered apps lean toward sessions; APIs and SPAs toward tokens.
- Session:
AddAuthentication().AddCookie(); to scale out, a distributed session/ticket store (Redis). - Token:
AddJwtBearer(); short access token + refresh token, and a denylist or short lifetimes for revocation. - Cookies (session or an encrypted token in a cookie) are safer against XSS if
HttpOnly; tokens in JS storage are exposed. - Server-rendered app → cookie/session. SPA/mobile/API → token (often via a BFF holding it in a cookie).