What Does Authentication Do?

1 OF 5 · THE PROBLEM

Servers forget you between requests

Each time your browser asks a server for something, the request arrives on its own. HTTP, the protocol the web runs on, doesn't connect one request to the next. That's by design: no server or database has to keep track of every visitor in real time. So after you log in, the server still needs a way to recognize your next click.

There are two common answers. With a session, the server keeps a list of who's logged in and gives your browser an ID to send back, usually in a cookie. With a token, the server gives you a signed pass that says who you are, and keeps no list at all. This page shows the token approach.

First, here's what happens when a request arrives with no pass:

The server answers with status code 401, which means "I don't know who you are." Its neighbor, 403, means "I know who you are, and the answer is no." That's the difference between authentication (who you are) and authorization (what you're allowed to do). Watch out for the names, though: 401's official name is "Unauthorized", which sounds like 403's job. In practice, 401 means "log in first", and 403 means "logging in won't help".

2 OF 5 · THE PASS

What's inside a token

On a real site you'd log in with a password and get a token back. Nobody needs an account here, so this page got an anonymous token the moment it loaded. Your browser sends it with each request in a header called Authorization, as Bearer followed by the token.

A token is three chunks of text joined by dots. The header says how the token was signed. The payload holds claims, the facts the token vouches for: sub is who it belongs to, aud is which site it's for, iat and exp are when it was issued and when it expires (in seconds since January 1, 1970), and jti is a unique ID. The third part is the signature.

The header and payload are encoded with Base64URL, which writes any data using only letters, numbers, - and _. None of those characters mean anything special in a web address, unlike / or ?, so a token can travel in a link or a header without being changed. Encoding isn't encryption. Anyone holding the token can read them, as the button below does, so a token should never carry secrets.

3 OF 5 · THE SIGNATURE

How the server knows it's real

If anyone can read the payload, what stops someone from writing their own? The signature. The server makes it by running the header, the payload and a secret key through a function called HMAC-SHA256. The result works like a fingerprint: the same input always gives the same fingerprint, changing a single character gives a completely different one, and without the secret key there's no way to produce a matching one.

When a token comes back, the server computes the fingerprint again and compares. If they match, the token is genuine and unchanged, and the server didn't have to look anything up in a database.

Now try to cheat. Change anything in the payload, like the expiry time or the sub, and send it with the original signature.

The server also accepts only one signing method, HS256. That closes a well-known hole: some early JWT libraries trusted a header that said "alg": "none", meaning "no signature needed", and accepted forged tokens as genuine.

4 OF 5 · EXPIRATION

Why tokens expire quickly

The server keeps no list of the tokens it handed out, so it can't take one back. If someone steals a token and uses it before it expires, the server treats them as you. That's why tokens like this usually last minutes, not days. This one lasts 15. Skip ahead and watch the same token stop working.

Real apps pair a short-lived token with a longer-lived refresh token. The app uses the refresh token to get a new short-lived one without asking for your password again, and the server can cancel a refresh token when you log out. The refresh button here just asks for a new anonymous token.

5 OF 5 · TRADE-OFFS

Sessions or tokens?

Tokens help when many servers need to check who you are. Any server with the key can verify a token on its own, without asking a shared database. Some signing methods use a key pair, so services can verify tokens with a public key that can't create new ones.

Sessions are easier to cancel. Delete the entry on the server and you're logged out everywhere at once, which is harder to do with tokens.

Where the browser keeps a token is a security choice too. In a cookie marked HttpOnly, the page's own scripts can't read it, which protects it if someone manages to inject code into the page. In the browser's local storage, any script on the page can read it. This page keeps its token in memory and forgets it when you leave.