Sessions, Tokens, JWT and OAuth

In this chapter

We'll learn how a website keeps you logged in after the password check — sessions, tokens and JWTs — and how OAuth lets you sign in with another account without sharing your password, explained as a cloakroom ticket, a signed festival wristband and a car's valet key.

14–16 min

The Problem in Real Life

In Act 12, Anna fixed a checkout bug with cookies and sessions. Now she's reading about the three hundred hijacked accounts and wonders: "Once a bot logs in, what does it actually hold that lets it keep acting as the fan?"

John also has news: venues have asked for "Sign in with Google", and the new mobile app team wants to use JWTs. "Same question, three answers," he says. "Let's look at what proves you're logged in."

So after login, a small piece of text is all that stands between an attacker and the account?

Anna

Typing Your Password on Every Click vs. Carrying Proof

HTTP forgets you

Every request stands alone (Act 12). Something must prove who you are on each one.

Proof can be stolen

Whatever proves you're logged in is as valuable as your password while it's valid.

Logging in with other accounts

Users want "Sign in with Google" — without giving their Google password to anyone else.

After the password check: once you're authenticated, the server gives your browser or app a piece of proof to send with every later request. There are two main styles of proof, plus a way to log in using another company's account.

Session — a cloakroom ticket: at a cloakroom, you hand over your coat and get a ticket with just a number. The ticket itself says nothing; the cloakroom keeps the coat and the record. A session works the same way: the server stores "session 7f3a... = fan #48213, logged in at 10:02" and gives the browser only the session ID in a cookie (Act 12). Logging out or banning a user is easy: the server simply throws the record away.
Token — proof the client carries: a token is a string the server gives the client to send with each request, usually in a header: Authorization: Bearer <token>. Mobile apps and APIs often use tokens. Some tokens are random (like a session ID); others carry information inside them.
JWT — a signed festival wristband: a JWT (JSON Web Token, said "jot") is a token with information printed on it — who you are, your role, when it expires — plus a signature, like a hologram on a festival wristband. Anyone can read it (it's only encoded, not encrypted — so never put secrets in it). But nobody can change it, because the signature would no longer match, and only the server has the key to make valid signatures. The server can check a JWT without looking anything up, which is why it's popular for APIs and many servers.
The catch with JWTs — hard to take back: a wristband stays valid until it expires, even if you'd like to cancel it. So JWTs are given short lifetimes (like 15 minutes) and renewed with a separate refresh token that the server can cancel.
Protecting the proof: a stolen session ID or token works like the password until it expires. So: send it only over HTTPS; in browsers, keep it in a cookie marked HttpOnly (JavaScript can't read it), Secure (HTTPS only) and SameSite (next chapters); give it an expiry; and issue a new session ID after login.
OAuth — the valet key: some cars come with a valet key: it starts the car and drives it, but can't open the boot or the glovebox. You give the parking attendant that key, never your main key. OAuth is the valet key for accounts. When a venue clicks "Sign in with Google", BlueTicket sends them to Google, they log in at Google (with Google's MFA), and Google gives BlueTicket a limited token that says "this is maria@riverside.example, and you may read her name and email" — nothing more. BlueTicket never sees the Google password. (Strictly, the login part is a layer on top of OAuth called OpenID Connect.)

Table — Session vs. JWT

Feature	Session (cloakroom ticket)	JWT (signed wristband)
What the client holds	A random ID	Readable claims + a signature
Where the details live	On the server (e.g. Redis)	Inside the token
Server must look it up?	Yes	No — just check the signature
Cancel it early	Easy — delete the record	Hard — wait for expiry (keep it short)
Common use	Websites	APIs, mobile apps, many servers

Table — Inside a JWT (decoded)

Part	Example	Meaning
Header	{ "alg": "HS256" }	How it's signed
Payload	{ "sub": "48213", "role": "fan", "exp": 1765000000 }	Who, what role, expires when
Signature	Xk3...9fQ	Proof the server made it — changes if anything is edited

Anyone can decode the header and payload. Never put passwords or personal secrets in a JWT.

A safe session cookie

Set-Cookie: session=7f3a91c2e8...; HttpOnly; Secure; SameSite=Lax; Max-Age=86400; Path=/

# HttpOnly  -> page JavaScript can't read it (protects against XSS, chapter six)
# Secure    -> only sent over HTTPS (chapter four)
# SameSite  -> not sent on most requests from other sites (protects against CSRF, chapter six)
# Max-Age   -> expires after one day

BlueTicket's choices: the website keeps sessions in HttpOnly, Secure, SameSite cookies, stored in Redis (Act 14) — easy to cancel. After Sunday's attack, Anna adds a button for fans: "Log out of all devices", which deletes all their sessions. The mobile app uses short-lived JWTs (15 minutes) plus refresh tokens that are cancelled when a fan resets their password. Venues get "Sign in with Google" through OAuth / OpenID Connect, so their staff use their own company accounts with MFA.

Key Takeaway

After authentication, the client carries proof on every request. A session is a cloakroom ticket: just an ID in a cookie, with the record kept on the server — easy to cancel. A JWT is a signed wristband: readable information plus a signature nobody can forge; checked without a lookup, but hard to cancel, so keep it short-lived. Protect any proof with HTTPS, HttpOnly/Secure/SameSite cookies and expiry. OAuth is a valet key: logging in at Google gives an app limited access without ever sharing the password.

Why This Matters

Every login system you'll build or use relies on sessions or tokens, and many apps offer "Sign in with..." through OAuth. Knowing how they work — and how they're stolen — helps you choose the right one, store it safely and explain the trade-offs, which is a very common interview question.

"Only sent over HTTPS" keeps coming up. Anna knows from Act 12 that HTTPS means a padlock and a handshake. But what does encryption actually do — and what about data that's just sitting in the database?