Course outline · 0% complete

0/29 lessons0%

Course overview →

Sessions vs Tokens

lesson 7-2 · ~11 min · 21/29

HTTP forgets everything

HTTP is stateless: every request arrives with no memory of the previous one. The server that checked Ada's password at 9:00 has no idea the 9:01 request is also Ada, unless the request carries proof.

Two strategies dominate:

  • Sessions: after login, the server creates a record in a session store ("session s1 = ada") and gives the browser only the random id, usually in a cookie (a small value the browser automatically re-sends with every request). Each request looks the id up.
  • Tokens: after login, the server hands back a signed token containing the data itself ("user 42, expires Friday, signature"). Each request presents the token, and the server just verifies the signature. No store, no lookup.

Same goal, opposite trade-offs, and the diagram shows the moving parts.

Sessionbrowserserversessionstorecookie: s1who is s1?Tokenbrowserserver verifiessignature onlytoken: user 42 + signaturesession = id + lookup, token = self-contained proof
Sessions carry an id and look the user up. Tokens carry the data and only need a signature check.

Code exercise · javascript

Run this complete session mechanism: login creates a store entry and returns the id, whoAmI looks it up. An unknown id means anonymous.

Quiz

A user clicks "log out everywhere" after their laptop is stolen. Which auth strategy handles this instantly, and why?

Code exercise · javascript

Your turn. Add logout(sessionId): remove the session from the Map and return true if it existed (Map has a delete method that returns exactly that boolean).