Tokens or sessions: which problem are you solving

JWT Authentication Course · lesson 8 of 13 · 5 min read

Stateless is a trade, not an upgrade.

Open this lesson in the learning hub

Key points

  • A session stores state on the server and gives the browser an opaque id. Every request looks the state up, so revoking access is instant - you delete the row.
  • A JWT carries its own claims and is verified by signature alone. No lookup means any instance can serve any request, which is what makes it attractive for scaled-out APIs.
  • The cost is revocation. Nothing is consulted at validation time, so a stolen token stays valid until it expires - and shortening the lifetime just moves the cost to refresh traffic.
  • A token is also bigger than a session id, and it is sent on every request. A fat token with many claims is bandwidth you pay for constantly.
  • The honest default for a browser application talking to your own backend is a session cookie. It is simpler, revocable, and the scaling problem it supposedly has is solved by a shared session store.
  • JWTs earn their place between services, for third-party API access, and where the verifier genuinely cannot call the issuer on each request.

Example

# SESSION                                JWT
#
# Cookie: JSESSIONID=a1b2c3              Authorization: Bearer eyJhbG...
#   ~32 bytes                              ~500-1500 bytes, every request
#
# server looks up the session            server verifies a signature
#   -> needs shared state                  -> needs no state
#   -> revoke = delete the row             -> revoke = ...not really possible
#
# CHOOSE A SESSION WHEN:
#   - a browser talks to your own backend
#   - you must be able to log someone out immediately
#   - permissions change during a session and must take effect now
#
# CHOOSE A JWT WHEN:
#   - service to service, where a lookup per call is too expensive
#   - a third party must verify without calling you
#   - the verifier is in another trust domain
#
# THE COMMON MISTAKE:
#   using a JWT for a normal web app "because it scales", then adding a
#   denylist so logout works - which reintroduces the shared state you
#   removed, with none of the simplicity you gave up.

Sessions are revocable and simple; JWTs are stateless and cannot be taken back - pick the one whose trade you actually want.

When NOT to use a JWT Validating a token, step by step

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the JWT Authentication Course course, and every lesson in it is listed on the JWT Authentication Course contents page.