Web Auth

Identification, authentication and authorization are three different questions, and a web server has to answer all of them again on every single request.

Why a chosen password has to be stretched rather than hashed, how to set the parameters, and what the standards actually say once you read them.

Trading a password for an unguessable identifier that names a row on the server, and the six cookie attributes that decide whether it survives the browser.

Moving the session state into a signed token buys statelessness and pays for it in revocation, and the bill comes due exactly when you most need to sign someone out.

One attack spends your cookie without asking and the other runs the attacker's code inside your origin, and only one of them can be fixed with a header.

Sign-up, verification and reset each mint a credential by email, which makes the reset link a password equivalent and the whole set a map of who has an account.

Six digits from an HMAC and a clock, built from the RFC up, plus the honest limits: it is phishable, and the recovery codes behind it are usually the weakest part.

A key pair whose signature covers the origin, so a phishing site cannot obtain anything it can use, plus the two ceremonies and what the server actually checks.

Delegating authentication to a provider the user already trusts, held together by an authorization code, PKCE and state, and the difference between a token that grants access and one that says who someone is.

A session says who, never what, so every request needs a second check, and the three ways of writing it cost very different amounts to change later.