Go One Layer Deeper
One ordinary line of code, expanded downward. Every layer names what it hides for you, how it fails, and where to learn it properly. Descend as far as the problem requires — and stop.
await fetch('/api/users')SELECT * FROM users WHERE email = 'alice@exaawait userRepository.save(user)$ git push # …and it is liveagent.run("refund the duplicate charge for oawait auth.signIn(email, password)await stripe.charges.create({ amount: 4990 }open('out.txt', 'w').write(data)items.sort((a, b) => a.score - b.score)
One login, all the way down
Depth
An identity provider gives you authentication. Knowing exactly where its guarantee stops is what prevents the most common serious vulnerability in web applications.
1await auth.signIn(email, password)- 1
1/7 layers · Enough to build
Why should an application engineer care?
Teams routinely adopt a provider and assume access control is handled. It is not: the provider establishes who, and your code still has to decide what they may touch.
The question this ladder asks
Which security guarantees are you delegating?
What are you delegating to an identity provider? →Where this goes wrong in production
- Identity provider adopted↓
- Authorization assumed handled↓
- Resource id changed in URL↓
- Cross-tenant data disclosure
What are you delegating here?
What are you delegating to an identity provider?
SecurityYou write
1const session = await auth.signIn({ email, password })The abstraction handles
- ✓Password hashing with a sane work factor
- ✓MFA, passkeys, breach-password detection
- ✓Rate limiting on credential endpoints
- ✓Session or token issuance and signing
- ✓Social login, SSO, the compliance paperwork
Still your responsibility
- →Authorization — the provider establishes *who*; your code still decides *what they may touch*
- →Token handling in the browser —
HttpOnly,Secure,SameSite, storage location, lifetime - →Revocation — a self-contained token outlives the user's logout unless you designed for it
- →Object-level checks — the user changes an id in the URL; only your code notices
- →Which database role executes the query — a broad role means one authorization bug reaches every row
Know your escape hatch
When: You need to answer "may this principal do this to this resource" — the provider never had that information.
Drop to: Your own authorization layer: explicit checks at the resource, scoped roles, an audit trail.
Adopting a provider and assuming access control is handled is the most common serious vulnerability in web applications.