Sessions vs JWTs: Choosing an Authentication Strategy

After a user signs in, every later request must prove who they are. The two common approaches are server-side sessions and self-contained tokens (JWTs).

Server-side sessions

Browser cookie:  sid=7f3b2c1e...           (random, meaningless on its own)
Server store:    sess:7f3b2c1e -> { userId: 42, createdAt: ..., mfa: true }

• Easy revocation: delete the record and the user is signed out everywhere.
• Small cookie, sensitive data stays on the server.
• Needs a shared store (database or Redis) when you have several servers.

JWTs

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsImV4cCI6MTc2MDE3MjYwMH0.4k2...
header             . payload (user id, expiry, claims)        . signature

• Stateless verification: any service with the key can check the token without a database lookup.
• Hard to revoke: a stolen token works until it expires, unless you add a denylist (which brings back state).
• Payload is readable by anyone (it's only base64-encoded); never put secrets in it.

A sensible default

• Browser web apps on one domain: sessions in HttpOnly, Secure, SameSite cookies. Simple and secure.
• Mobile apps and third-party API clients: short-lived access tokens (often JWTs) plus refresh tokens.
• Service-to-service: JWTs or mTLS, verified at each service.

If you use JWTs

• Keep access tokens short-lived (minutes) and use refresh token rotation.
• Store them in HttpOnly cookies in browsers rather than localStorage, which any XSS can read.
• Verify signature, expiry, issuer and audience on every request.

Whatever you choose, use a well-maintained auth library or provider instead of building cryptographic token handling yourself.