Authentication and authorisation
Who are you, and what may you do? Store passwords so a breach is survivable, pick factors that resist phishing, and check permission on every object.
30 min7 steps
By the end you can
- Distinguish authentication from authorisation and place each check at the right layer
- Explain how slow, salted password hashing turns a stolen table into an expensive attack
- Choose authentication factors by how well they resist phishing and replay
- Enforce object-level authorisation on every request that names an object
- Choose between role-based, attribute-based and relationship-based authorisation
Two different questions
AuthN: who is calling? AuthZ: may they do this action on this resource? AuthZ runs on every request.
Store passwords for the day you are breached
Assume the table leaks. Use a slow, memory-hard hash (Argon2id, scrypt, bcrypt) tuned to tens of ms, plus a unique random salt per user. Never use a fast hash such as SHA-256.
Fast hash, no salt
- Billions of guesses/s
- One pass cracks everyone
- Same password, same hash
Argon2id + salt
- Tens of ms per guess
- Separate pass per user
Loading question…
Factors that resist phishing
Typed codes (SMS, app) can be relayed by a phishing page in seconds. WebAuthn and passkeys sign a challenge bound to the site origin, so a look-alike domain gets a useless signature.
Check the object, every time
Top of the OWASP API Top 10 (2023): BOLA / IDOR. The API authenticates, then loads /invoices/8812 without checking it is yours. Check permission on that object, server-side, every time. Random IDs are not authorisation.
Roles, attributes or relationships
RBAC
- Users get roles
- Easy to audit
- Weak per-object
ABAC
- Policy over attributes
- Expressive
- Hard to audit
ReBAC
- Graph of relationships
- Folders, groups, sharing
- Zanzibar (Drive)
Where each check runs
Each check runs where the information exists. Only the service that loads the object can decide object-level access.
Order the checks an API request passes through.
- 1The gateway checks coarse permissions, such as the token's scope for this API
- 2The service loads the requested object
- 3TLS terminates and the request is parsed
- 4The gateway validates the access token and identifies the caller
- 5The service checks the caller's permission on that object, then acts and responds
Check your mastery
Score 80% or more.
Mastery check
3 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
Next: sessions vs JWT.
Answer this step to continue.