Question
Why does web authentication need extra machinery like cookies, tokens, or signatures in the first place?
Answer
HTTP is stateless — the server forgets you the instant a request finishes, so every authentication scheme exists to re-prove identity on each new request.
A web server handles thousands of independent requests. By design, HTTP keeps no memory between them: two requests from the same browser look, to the server, like requests from two strangers.
That statelessness is a feature for performance — requests are independent and can be answered in parallel, very fast. But it means there is no built-in concept of "being logged in." Every approach to web auth is really an answer to one question:
How does the client re-prove, on every single request, that it already authenticated earlier?
The three mechanisms in this topic are three different answers:
| Mechanism | How identity is re-proven each request |
|---|---|
| Cookie-based | Browser resends a session-ID cookie; server looks up the session |
| OAuth 2.0 / OIDC | Client presents a token (often a JWT) issued by an identity provider |
| WebAuthn | Authenticator signs a fresh challenge with a private key |
Tip: Hold onto the phrase "stateless HTTP" — it's the root cause that every card here circles back to.
Go deeper:
MDN: HTTP overview — "HTTP is stateless" — MDN's statement of the statelessness that forces every re-proof scheme.
OAuth 2.0 and OpenID Connect (in plain English) — frames web-auth as answers to "how do I re-prove identity each request".
Note saved — thanks!