Passwords
Authentication checks who you are: logging in proves you are Ada. Authorization decides what you may do once the server knows that: Ada may read her own messages, not anyone else's. The server makes both decisions, never the browser alone.
Ada signs up. Her browser sends her name and a new password to the server over HTTPS, so nobody on the way can read them. The server must not save that password as it is: one leaked database would expose every account.
Instead the server picks a salt, 16 random bytes, and runs a slow hash over salt plus password. A hash works one way only: it cannot be turned back. The server keeps the user, salt and hash. OWASP recommends Argon2id, scrypt or bcrypt.
Later Ada logs in. The browser sends her name and the password she typed, again over HTTPS. The server has no copy of her real password to look at, only the salt and the hash it saved.
The server hashes the typed password with Ada's saved salt and the same settings. Same password, same hash, so they match: it is Ada. A wrong password gives a completely different hash, and the reply just says wrong name or password.
Sessions
Typing the password on every click would be painful, so the server starts a session. It makes a session ID from 32 random bytes that nobody can guess, and stores it in its session table beside ada and an idle limit.
The server sends the ID back in a cookie marked HttpOnly (page scripts cannot read it), Secure (sent over HTTPS only) and SameSite (held back from most requests other sites start). The browser keeps the cookie; the server keeps the row.
Now each request carries the cookie by itself. The server looks the ID up: the row says ada, so she is authenticated. Then authorization: may ada open this inbox? It is hers, so yes.
Logging out deletes the row on the server and tells the browser to drop the cookie. A stolen copy of the old ID now matches nothing. Sessions also end by themselves after a stretch with no activity.
Tokens and MFA
Some apps hand out a signed token instead, often a JSON Web Token (JWT). The user and an expiry time sit inside it, with a signature. The server checks the signature, no table lookup, but cannot easily cancel the token early.
Multi-factor authentication asks for a second proof besides the password: a six-digit code from an app on Ada's phone, which changes every 30 seconds, or a security key. A stolen password alone is then not enough.
What happens
;; step 1/11 · authn-authz
authentication who are you?
log in: prove you are ada
authorization what may you do?
ada may open ada's inbox
both are decided on the server: anything the browser
decides on its own can be changed by whoever holds it
slow_hash on the card is Python's hashlib.scrypt with OWASP's minimum settings (n=2**17, r=8, p=1), which needs 128 MiB of memory per try. That cost is small for one login and huge for someone trying billions of guesses. Argon2id is OWASP's first choice where it is available. The salt in the figure is fixed so you can check the numbers; a real server draws a new random salt for every password, so two people with the same password still get different hashes.