Sessions vs Tokens

The password is verified once. On the next request, 200 milliseconds later, the service must know it is the same buyer without asking again, and there are two ways to do that. A session: the server writes "session 7f3a belongs to user 812" in a store it controls, and the client carries only the id. A token: the server signs the statement "user 812, until 19:57" and the client carries the statement itself. The first costs a lookup on every request and can be revoked by deleting one row. The second costs nothing to verify and cannot be taken back until it expires.

Stagedoor's first implementation had one mechanism for every client, a JWT that lived until the browser closed, and the security review found it could not be revoked, was readable by any script on the page, and had been copied into the mobile app's crash reports. Marek's rebuild uses both designs on purpose: the browser gets a session in an HttpOnly cookie, the mobile app gets a 15-minute access token paired with a 30-day refresh token that is, on inspection, a session by another name, and the scanner carries its API key in the same header. Both paths end in the same Principal in the request context, and nothing below the auth ring knows which one produced it.

The Session

At login the service draws 128 bits from the operating system's random source, encodes them as 22 URL-safe characters, and that string is the session id. It writes a hash of session:{id} to Redis with the user id, the creation time, the last-seen time and the client that logged in, and sets a TTL of 30 days. The id goes back to the browser in a cookie, Secure, HttpOnly, SameSite=Lax, as Chapter 2 specified. On every request the auth ring reads the cookie, fetches the hash from Redis in 200 microseconds, and builds the principal from the user id inside it. The id itself means nothing: it is a key, not a claim, and 128 bits of randomness means guessing one is not a strategy.

Revocation is a delete. Logout deletes session:{id}. "Sign out everywhere," the button a buyer presses when her laptop is stolen, deletes every id in the set user-sessions:{user_id} that the login path added to. An organizer removing a staff member deletes that person's sessions, and the removed staff member's next request, 200 milliseconds later, is a 401. The stolen cookie is dead the moment the row is, and there is no expiry to wait out. That single property is the reason the browser gets a session, and the rest of the topic is about what the other design gives up to avoid the lookup.

The Bearer Token

A bearer token is a signed statement the client presents in Authorization: Bearer, and whoever bears it is believed. The server verifies the signature and reads the claims, user 812, expires 19:57, with no store involved: verification is a signature check in memory, and a service that has the key can accept a token it never issued, which is what makes tokens right for the places sessions cannot reach. The trade is that the server has no row to delete. A stolen token is valid until exp, and the only way to shorten that window is to make the token short.

So the access token lives 15 minutes. That is short enough that a token lifted from a crash report is probably expired before anyone reads it, and long enough that the app is not re-authenticating on every tap. To get a new one without a password, the app holds a refresh token: 256 random bits, valid 30 days, stored server-side as a hash with the user id and the device, presented once to POST /token to receive a fresh access token and a fresh refresh token, at which point the old refresh token is dead. A refresh token that is presented twice is a stolen one, and the service revokes the whole family. Read that description again: a random id, a server-side row, a delete to revoke. The refresh token is a session. The token design does not remove the lookup, it moves the lookup off the hot path, from every request to once per 15 minutes.

# the browser: a cookie the server can look up and delete
Cookie: sd_session=Vv1c3aG0kM7yQx2bR8hN4w
  Redis  session:Vv1c3aG0kM7yQx2bR8hN4w  ->  {user_id: 812, created: ..., last_seen: ..., client: web}  TTL 30d

# the mobile app: a signed statement, verified in memory, gone in 15 minutes
Authorization: Bearer eyJhbGciOiJFZERTQSIsImtpZCI6IjIwMjYtMDkifQ.eyJzdWIiOiI4MTIiLCJleHAiOjE3OTA0NTI2MjB9.…
  claims  {sub: "812", exp: 19:57}       # no lookup; a row exists only for the refresh token

# both end here, and the domain never learns which path produced it
Principal(user_id=812, organizer_id=None, roles={"buyer"}, via="session")

The top half is the cookie and the Redis row it points at: the id carries no information, the row carries all of it, and the row has a TTL. The middle is the bearer token, three base64 segments the next topic takes apart, whose claims are the information and whose signature is the proof, with no row at all until the app needs a new one. The bottom is what the auth ring produces in both cases: one Principal with the user, the organizer if any, the roles, and a note of which mechanism established it, which the audit log records and nothing else reads.

Which Client Gets Which

The browser gets the session. The cookie is automatic, so the frontend writes no code to attach it; it is HttpOnly, so an injected script cannot read it; and it is revocable, which for a client that lives on shared laptops and in internet cafés is the property that matters. The one thing the cookie costs is SameSite discipline, which Chapter 2 paid.

The mobile app and the scanner get tokens. They have no cookie jar worth trusting, they attach Authorization explicitly on every call, and they run in places where a lookup on every request is the wrong trade: the scanner reads 2,000 tickets in the 40 minutes before a show, and a Redis round trip on each is 2,000 round trips the signature check does not need. The scanner's credential is an API key rather than a user's token, which Topic 28 covers; the mobile app's is the access-and-refresh pair. In every case the auth ring produces the same Principal, and the domain's get_order(principal, public_id) of Topic 29 is written once.

Revocation Is the Whole Difference

Every other difference between the two designs is a matter of cost. The one that decides is what happens when a credential must stop working before its time. A session is revoked by deleting it. A token is revoked by waiting for exp, or by keeping a denylist of revoked token ids that the verifier checks on every request, which is a session store with the polarity reversed and the same Redis round trip. Any design that needs instant revocation needs a lookup somewhere, and the honest question is only where to put it.

Stagedoor's answer is to put the lookup where the requirement is. The browser's session is looked up on every request, because the buyer on a stolen laptop needs it gone now. The app's access token is not looked up at all for 15 minutes, because the app is on a device the buyer holds, and the refresh token behind it is looked up once per 15 minutes and is the thing "sign out everywhere" deletes. A staff member removed by an organizer mid-shift is the hard case: the removal must take effect before any token expires, and Topic 29 handles it by reading the current role from the store at check time rather than trusting a role claim, which is the session's cheap lookup again, spent on the one fact that changes.

Where the Session Lives

Redis, with a TTL, on redis-01. Sessions are read on every request that carries a cookie, most of the 3,000 a second at on-sale, and a lost session is a re-login rather than a lost order, which is the profile Redis is for. The Postgres alternative puts thousands of point reads a second on pg-primary for data that is never joined and never reported on, and the pool of 20 was sized for checkout. The in-process alternative, a dictionary in the api process, is the design Stagedoor had before it had two instances: api-02 does not know the session api-01 created, and login works exactly as often as the load balancer happens to send both requests to the same host, which Chapter 14 names as the sticky-session lie.

Sliding vs Fixed Expiry

A session that extends its TTL on every request lives as long as the buyer is active, which is what a buyer expects and what an attacker with a stolen cookie enjoys equally. A fixed absolute limit caps it regardless of activity. Stagedoor does both: the auth ring resets the TTL to 30 days on each request, and the session row carries its creation time, and a session older than 90 days is refused and deleted even if it was used a minute ago. The buyer re-authenticates once a quarter at most. The stolen cookie has a ceiling. And the creation time in the row is what support reads when a buyer asks why she was signed out, which turns "the session expired" from a guess into a timestamp.