TL;DR: Authentication verifies who a principal is; authorization decides what that principal may do with a specific resource. Authentication usually fails through stolen or phished credentials and stolen sessions. Authorization usually fails through missing checks on specific objects (IDOR), missing checks on privileged functions, checks placed in the client, and stale permissions. The second category causes more breaches, because authorization must be right on every endpoint while login lives in one place.
How to approach it
Define both in a sentence each, then make the answer about failure modes with examples. Finish with the design rules that prevent authorization bugs, since that is what the interviewer will probe next.
A strong answer
Request
GET /invoices/17
Authentication
session or token valid
Authorisation
user 42 owns invoice 17?
Resource
returned or 403
How each fails
Authentication failures
- Phished or stuffed credentials, stolen sessions
Authorisation failures
- IDOR: no check on this object
- Missing role checks on admin functions
Definitions. Authentication establishes a principal by verifying a credential (password plus second factor, passkey, client certificate, signed workload token). Authorization takes the principal, the action and the specific resource and returns allow or deny, every time.
Where authentication fails.
- Phished or reused passwords without phishing-resistant MFA.
- Session or token theft (XSS reading tokens, tokens in logs, malware).
- Weak recovery flows that bypass the strong login.
- Service credentials that never expire and leak through code or CI logs.
Where authorization fails.
| Failure | Example |
|---|---|
| Object-level (IDOR / BOLA) | GET /orders/8812 returns another customer's order |
| Function-level | A regular user calls /admin/users/export directly |
| Client-side enforcement | Role taken from a hidden field or a mobile app's local flag |
| Tenant isolation | Query filters by object ID but not by tenant ID |
| Stale decisions | Access continues after a user leaves the project |
| Delegation | An agent or service acts with its own broad permissions instead of the user's |
OWASP's web Top 10 has ranked broken access control first since 2021, and its API Top 10 lists broken object-level authorization first. The reason is structural: every endpoint and every object needs a check, and forgetting one is enough.
Rules that work. Authorize on the server for every request; check the specific object, not just that a user is logged in; deny by default; centralise policy in a shared library or service so checks are consistent and testable; and write negative tests ("user A requests user B's object, expect 403") for every resource type.
The AI angle. An LLM feature that fetches records by an ID the model supplies is an IDOR waiting to happen. The tool must authorize against the session's user, not trust the model's arguments.
What interviewers probe next
- "How would you find IDORs across a large API?" Automated tests with two users per resource type, plus reviewing that every data access goes through the authorization layer.
- "Where should authorization logic live in microservices?" In a shared policy engine or library called by each service, with the decision made close to the data.
- "Is MFA an authorization control?" No, it strengthens authentication; it does nothing for a missing ownership check.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A logged-in user of a project-management app opens /projects/42/settings, a project they do not belong to, and the page loads.
Start here
Which control failed here?
Did the app know who the user was?
Authorisation. Authentication confirmed who the user is; the server never checked whether that user may access project 42's settings. This is an insecure direct object reference: the object ID came from the user and nothing tied it to their permissions.
Carry it forwardAuthentication says who; authorisation says what they may do.
Weak answerBlaming the login system.
Constraint changes
Why are authorisation failures more common than authentication ones?
How many places must each control be correct?
Login lives in one place and gets attention. Authorisation must be right on every endpoint and every object: each new route, API or background job is a new chance to forget a check. That is why missing object checks cause so many breaches.
Carry it forwardAuthorisation must be correct everywhere.
Weak answerAssuming a secure login makes the app secure.
Constraint changes
What if the check exists only in the front end, by hiding the link?
Can the user call the API directly?
The server still serves the page to anyone who types the URL or calls the API. Checks in the client are user experience, not security. Every server endpoint must check the user's permission on the specific object.
Carry it forwardAuthorisation must be enforced on the server.
Weak answerHiding buttons as access control.
Constraint changes
How would you fix it systematically?
How do you stop the next developer forgetting?
Load objects through a function that takes the current user and checks membership, so routes cannot fetch objects without a check; deny by default; and add tests that call each endpoint as a user without access and expect a refusal.
Carry it forwardMake the safe path the only path, and test denial.
Weak answerPatching this one route.
Constraint changes
What if the user was removed from the project yesterday?
Where does the app read the user's memberships from?
Permissions must be checked at request time against current data, not cached in a long-lived token or session. Otherwise removed members keep access until their token expires. Revocation is part of authorisation.
Carry it forwardCheck current permissions, not stale copies.
Weak answerPutting roles in a long-lived token as the source of truth.
Now defend it
How would you prevent this class of bug?
Enforce authorisation on the server for every object, using access-checked loaders and deny-by-default routing; check current permissions at request time; keep client-side hiding as convenience only; and add negative tests that call each endpoint as an unauthorised user, run in CI.
How it's scored
Weak: Gives definitions only, or conflates the two ("they're logged in, so they're authorized").
Hire: Gives distinct failure modes for each with examples, emphasising object-level authorization.
Strong Hire: Explains why authorization fails more often, gives preventive design rules and tests, and extends to agents and delegated access.
Common mistakes
- Treating authentication as sufficient protection for data.
- Enforcing roles in the frontend.
- Forgetting tenant boundaries in multi-tenant queries.
- Letting model-supplied identifiers select data without checks.