HTTP is stateless—sessions and cookies remember users across requests. Node APIs often use JWT tokens or server-side sessions with express-session.
Session flow
- User logs in; server creates session record with random ID
- Server sends
Set-Cookie: sessionId=...with HttpOnly, Secure, SameSite flags - Browser sends cookie on later requests; server loads session data
JWT overview
Signed token in Authorization header—stateless verification, harder to revoke instantly without blocklists. Good for microservices; sessions simpler for monolith logout.
Cookie flags
- HttpOnly — JS cannot read (mitigates XSS theft)
- Secure — HTTPS only
- SameSite — reduces CSRF risk
Important interview questions and answers
- Q: Where store session data?
A: Server memory (dev), Redis (prod scale), or database—never sensitive data in unsigned client cookies. - Q: JWT in localStorage?
A: Risky—XSS can steal it; HttpOnly cookies or short-lived tokens with refresh patterns are safer.
Self-check
- What does HttpOnly prevent?
- Session vs JWT trade-off for logout?
Tip: Store session IDs in HttpOnly cookies; keep session data server-side—never put secrets in JWT payloads without encryption.
Interview prep
- JWT vs server session?
JWTs are stateless tokens (verify signature); server sessions store data server-side with a session ID cookie—sessions easier to revoke, JWTs scale without shared store.