Sessions and Tokens

Authentication answered "who are you?" once, at login. The problem: HTTP is stateless: the server forgets you the instant a response is sent. So after a successful login, how does the next request prove it's still you? The server hands the client a credential at login, and the client sends it back on every subsequent request. There are two ways to design that credential, and the choice shapes how your whole system scales.

So what is that credential? There are two designs. Either the server keeps the state and hands the client a pointer to it, or the server hands the client the state itself, signed so it can't be forged. The first is a server-side session; the second is a token.

Server-Side Sessions

In the session design, the server stores the session data (who you are, when you logged in) in its own store (memory, Redis, a database) and hands the client only an opaque random session ID Session ID An opaque random string stored in a cookie that the server uses to look up session data. The client holds only the ID; the actual session state stays on the server. , usually in a cookie. On each request the server looks the ID up.

• Stateful. The truth lives on the server. To scale past one server, every instance needs to reach a shared session store.
• Easy to revoke. Logging out, or banning a user, is just deleting the row. The next request fails to look up.

That shared session store is the catch: it's one more piece of infrastructure, and every server has to reach it on every request. The second design exists to remove it.

JSON Web Tokens (JWT)

A JWT JWT JSON Web Token: a compact, signed format for passing claims between parties. Three base64url-encoded parts (header, payload, signature) joined by dots. The payload is readable by anyone — only the signature proves it was issued by the right party. stores nothing on the server. At login, the server signs a token containing the user's claims and hands the whole thing to the client. On each request the server verifies the signature, no lookup needed, because the token carries its own data.

Look at one and you'll see two dots. They split the token into three parts (a header, a payload, and a signature), each base64url-encoded:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMTM4Iiwicm9sZSI6ImVkaXRvciJ9.K3v...signature
└────── header ──────┘ └──────────── payload (claims) ───────────┘ └ signature ┘

Heads-up: the payload is signed, not encrypted: it's only base64-encoded, so anyone holding the token can read every claim in it. The signature stops tampering, not reading. Never put secrets in a JWT, and treat it like the password it effectively is. The signing key can be a shared symmetric secret (HMAC/HS256) or an asymmetric private key (RS256/ES256). The latter is common in OIDC, where the provider signs with a private key and the relying party verifies with the provider's public key.

In code, the whole lifecycle is two calls: sign at login, verify on every request:

import jwt from "jsonwebtoken";

// At login: sign a short-lived token with the user's claims
const token = jwt.sign({ sub: user.id, role: user.role }, SECRET, { expiresIn: "15m" });

// On each request: verify the signature and expiry (no database lookup).
// Always pin the algorithm list; never let the token pick its own.
const claims = jwt.verify(token, SECRET, { algorithms: ["HS256"] }); // throws if tampered with or expired

Why pin algorithms? The header names its own signing algorithm, and a verifier that trusts it can be tricked. An attacker can set alg: none to skip verification entirely, or downgrade an RS256 system to HS256 so the server's public key gets used as an HMAC secret, letting the attacker forge valid signatures. The fix: the server decides which algorithms it accepts, never the token.

What goes in the payload

The payload is just JSON, but the spec and the community have settled on conventions. Claims come in three flavors:

• Registered claims: seven names reserved by the spec, all optional but understood by every JWT library. Libraries enforce exp/nbf automatically; validating iss and aud keeps a token minted for one service from being replayed against another.

  Claim	Name	Purpose
  iss	Issuer	Who created and signed the token
  sub	Subject	Who the token is about, usually the user ID
  aud	Audience	Who may accept the token
  exp	Expiration time	Rejected after this moment
  nbf	Not before	Rejected before this moment
  iat	Issued at	When the token was created
  jti	JWT ID	Unique token ID, handy for denylists

• Public claims: community-standardized names, mostly from OpenID Connect: email, name, picture, email_verified, and friends. Use these instead of inventing your own spellings.
• Private claims: whatever your services agree on: role, plan, tenant_id. To dodge collisions with future standard claims, many teams namespace them (https://myapp.com/role); Auth0 requires it.

Two rules of thumb. Keep it small: the payload rides along on every request, and headers get rejected past a few KB. Store the user ID, not the user. And remember it's readable: no secrets, no PII you wouldn't put in a URL.

The trade-offs mirror the session design's, point for point:

• Stateless. Any server with the key can verify the token, so horizontal scaling is trivial: no shared session store.
• Hard to revoke. The token is valid until it expires; the server isn't consulting a store it can delete from. That's why access tokens are kept short-lived (minutes) and paired with a longer-lived refresh token Refresh token A longer-lived credential used to obtain new access tokens after the short-lived ones expire. Sent only to the authorization server token endpoint, never to resource servers. used to mint new ones.

Which to Use

Every row in this table is the same trade wearing a different outfit: sessions keep the truth on the server, JWTs hand it to the client. Decide where the truth lives and everything else follows.

Notice the pattern in the JWT column: every strength comes from having no store, and every weakness is the price of not having one. The revocation row deserves special attention. It's the one people get burned by. If "this account is compromised, cut it off now" is a requirement, a bare JWT can't deliver it.

So: sessions when you control the whole stack and instant logout matters, the classic web app. JWTs when there is no shared store to reach: stateless APIs, service-to-service calls, horizontal scale. And in practice, most real systems use both: a session cookie where the user logs in, short-lived JWTs between the services behind it.

Whichever design you pick, the client ends up holding a credential, and in a browser, where it holds that credential is its own security decision. That's the next lesson.