Login and sessions - who you are, on every request

Why this design

Every product with accounts has this system, and most security incidents involve some part of it: weak password storage, credential stuffing, a session that outlives a logout, a token that cannot be revoked. Interviewers use it to check that you know how passwords are stored, the difference between authenticating once and checking a credential on every request, and the real trade between server-side sessions and signed tokens - not the blog-post version where JWTs are simply better.

What you will learn

• How a password is stored (argon2id or bcrypt, with a per-user salt) and why the hash is slow on purpose.
• Why rate limiting must happen BEFORE the hash: one credential-stuffing attack can need hundreds of CPU cores otherwise.
• Opaque session ids against signed tokens: a lookup on every request against no lookup and no revocation.
• The hybrid most systems use: a 15 minute access JWT plus a rotating refresh token kept server side.
• Cookies done right: HttpOnly, Secure, SameSite - and what each one stops.

How to read this board

1. LOG IN · ONCE across the top: user, browser, the login service hex, the password hasher and the token signer.
2. STORES on the right: users, failed login attempts, and sessions with their refresh tokens.
3. EVERY REQUEST across the bottom: the API server hex checking tokens locally, the services behind it, the refresh endpoint and the red logout.
4. Press play, then read pages 1 to 6, then the DATA MODEL tables.
5. The conversation to have: what exactly happens to a stolen access token after the user logs out, and what you would pay to close that window.

Functional

• Sign up with email and password; log in; log out.
• Stay logged in across browser restarts for up to 30 days of inactivity.
• Every API request identifies the user without asking for the password again.
• Several devices at once, each a separate session the user can see and end.
• "Sign out everywhere" and password change end all other sessions.
• Lock out guessing: limit failed attempts by IP and by account.

Non-functional

• Checking a credential on a request: under 1 ms, and no single shared store on the hot path if it can be avoided.
• Login: under 500 ms including the deliberately slow hash.
• Passwords are never stored or logged in a recoverable form.
• A logout or revocation takes effect within a stated bound - this board says 15 minutes.
• Login availability 99.9 percent; request checking 99.99 percent (it is in front of everything).

Out of scope

• Social login and SSO (OAuth / OIDC with another provider) - the same session machinery after a different first step.
• MFA flows in detail. The login service is where they plug in.
• Authorisation (what a user may do) beyond carrying their id and roles in the token.