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, versus what you are allowed to do. Two different problems.
Sessions vs tokens (JWTs)
Server-side sessions versus stateless tokens. Revocation is the hard part with tokens.
Where the token lives
httpOnly cookies versus localStorage. Any script on the page can read localStorage, so an XSS bug hands over the token.
Expiry, refresh, and the rotation trap
With single-use refresh tokens, two tabs racing the same refresh will log the user out. Plan for it.
OAuth and social login
The redirect flow, the callback, and the state and next parameters.
Passwords
Never store plaintext. Hash with bcrypt or argon2. Better yet, don't handle them at all and 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 →