Who are you? vs. What are you allowed to do? Getting this distinction wrong is behind most access control bugs.
| Authentication | Authorization | |
|---|---|---|
| Question answered | Who are you? | What can you do? |
| Happens when? | At login / session start | On every request to a protected resource |
| Common mechanisms | Passwords, MFA, OAuth, SSO, certificates | RBAC, ABAC, ACLs, policy engines |
| Failure = ? | Anyone can log in as someone else | Logged-in users access things they shouldn't |
| OWASP category | A07:2021 Identification and Authentication Failures | A01:2021 Broken Access Control |
| Typical bug | Weak passwords, broken MFA, session fixation | IDOR, privilege escalation, missing function-level checks |
| Fix complexity | Well-understood — use established libraries | App-specific — every endpoint needs custom logic |
Authentication is largely a solved problem. Use bcrypt, enforce MFA, implement OAuth properly, and you're in good shape. Libraries handle most of it.
Authorization is where things fall apart. Every application has its own permission model, and every endpoint needs to enforce it. There's no generic library that says "user A can edit document 5 but not document 6." That logic is custom, and when it's missing, you get IDOR, privilege escalation, and broken access control — the #1 category on the OWASP Top 10.
I see this constantly in code reviews: the application checks that a request has a valid session token (authentication) but never checks whether that user should have access to the requested resource (authorization). The user is real. The request is legitimate. But they're accessing someone else's data.
Testing authentication: try default credentials, brute force, session fixation, token manipulation. Testing authorization: log in as user A, grab requests, replay them as user B. Use tools like Autorize (Burp extension) to automate the comparison.