securityAnswer last reviewed July 2026

For API auth, sessions or JWTs, how do you pick between them, and what do people usually get wrong about JWTs?

Strong answers weigh sessions against JWTs by what each one can actually do, with revocation front and center.

What an AI-prepared candidate might say

So sessions keep the state on the server. You log in, the server creates a session and sends back a session ID in a cookie, and then it looks that session up on every request. JWTs are the stateless version, the token itself carries the user's claims, signed by the server, so it can verify it without a lookup. A lot of APIs and microservice setups like JWTs because they scale without a shared session store. The catch is JWTs are harder to revoke, they stay valid until they expire. For cookies you want HttpOnly so JavaScript can't read them, Secure so they only travel over HTTPS, and SameSite to protect against CSRF. And keep token lifetimes short, with refresh tokens for longer sessions. It kind of depends on your architecture, but plenty of APIs run JWTs for the statelessness and just stay careful about storage and expiry.

Senior
Locked

Where a session and a JWT each keep their state, why revoking one is trivial and the other is a fight, and the cookie flags that decide if either is safe to ship.

Unlock the depth
Staff
Locked

The revocation and token-lifetime setup you'd actually defend in production, why localStorage is an XSS liability, and what you watch to keep token risk honest.

Unlock the depth
Follow-up chain
For API auth, sessions or JWTs, how do you pick between them, and what do people usually get wrong about JWTs? | NodeBook