Compare session-based authentication with token-based (JWT) authentication.

Summary

Sessions store state on the server and give the browser an opaque session ID cookie; token-based auth gives the client a signed token (often a JWT) containing claims that servers verify without a lookup. Sessions are simpler to revoke; tokens scale statelessly but are hard to revoke before expiry.

Longer Answer

Sessions: server-side store (Redis/DB), HttpOnly cookie, easy logout/revocation, needs CSRF protection, natural for browser apps. JWT: self-contained, good for APIs, mobile and service-to-service, but payload is readable (not encrypted), revocation needs short expiry plus refresh tokens or a denylist, and storing tokens in localStorage exposes them to XSS. Many modern web apps use sessions (or a BFF holding tokens) for browsers and JWTs for machine/API clients.

Key Points

• Sessions: stateful, easy revocation
• JWT: stateless, hard revocation
• Cookies need CSRF defenses
• localStorage tokens are XSS-exposed

Comparison / Tradeoffs

Common mistakes

• Long-lived JWTs with no revocation strategy
• Putting sensitive data in JWT payloads