Sessions, cookies and tokens — how an app remembers you

Sessions or JWTs — what is the real trade-off?

Revocation against lookup. A session id is a meaningless handle; the server holds the state, so signing someone out is deleting a row, at the cost of a store lookup on every request. A JWT carries signed claims, so any service can verify it with no shared state — and nothing can un-issue it before it expires. Everything else, including the "stateless scales better" argument, is smaller than that one difference.

The pattern that resolves it: a short-lived access token (minutes) plus a long-lived refresh token that IS checked against a store. You get stateless verification and a revocation point.

What is in the Authorization header, and what does "Bearer" mean?

A scheme and a credential: `Authorization: Bearer <token>`. Bearer means exactly what it says — whoever bears the token is treated as the subject, with nothing binding it to a device, a key or a client. That is why it must only ever travel over TLS, why it belongs in a header rather than a URL that lands in logs and referrers, and why its lifetime should be short.

How should a cookie holding a session be configured?

HttpOnly, so a cross-site script cannot read it. Secure, so it never leaves over plain HTTP. SameSite=Lax or Strict, which is what stops a third-party page from making an authenticated request on the user's behalf. Scope the Path and Domain as narrowly as the app allows, and give it an expiry rather than leaving it as a session cookie the browser may restore.

SameSite=Lax is a large part of why CSRF is less common than it was — but it is a default, not a substitute for a token on state-changing requests.