Auth & sessions
Get this wrong and it's a breach, not a bug.
Authentication is where 'works on my machine' meets a real attacker. The patterns are durable (sessions, tokens, expiry) even as the libraries churn, and the failure mode is catastrophic — so you own the boundary even when AI writes the wiring.
Ready to test yourself on this kind of call?
Work the incident scenario →What you own
- ▪The token storage + expiry/refresh strategy
- ▪The authorization rules (who can do what)
- ▪The threat model (what an attacker tries first)
- ▪Anything touching the security boundary
▸Hand to AI (4)
- Wiring an OAuth provider / SDK
- Route guards and middleware scaffolding
- A first draft of the session/user schema
- Tests for the happy + unhappy auth paths
What to learn (the durable stuff)
Authentication vs authorization
who you are vs what you're allowed to do.
Sessions vs tokens (JWTs)
server-side sessions vs stateless tokens, and why revocation is the hard part.
Where the token lives
httpOnly cookies vs localStorage, and why XSS makes localStorage risky.
Expiry + refresh, and the rotating (single-use) refresh-token trap
two clients racing the same refresh causes logout storms.
OAuth / social login
the redirect flow, the callback, and the state/next params.
Passwords
never store plaintext (hash with bcrypt/argon2); better yet, don't handle them at all (use OAuth).
Current tools (these change fast)
Practice this scenario
A user reports being logged out at random, and your logs show a storm of token-refresh requests returning 429. What's likely happening, how would you confirm it, and how do you fix it?
Work the incident scenario →