Security · 30 min read
Authentication vs Authorization
Authentication answers who you are. Authorization answers what you may do. Mixing them creates real security bugs even when login "works."
Why this exists
Login screens prove identity. Permission checks decide access. Teams often treat "the user is logged in" as enough to allow every action.
That conflation causes classic failures: any authenticated user can hit admin APIs, IDOR bugs let you read another user's objects, and UI hiding replaces server enforcement.
Cookies and sessions carry identity tokens. They do not define permissions by themselves. This lesson separates the two jobs so later web and API pages can speak precisely.
Axioms & primitives
- 01Authentication (authn) establishes identity to a useful confidence level.
- 02Authorization (authz) decides whether an identity may perform an action on a resource.
- 03Successful authentication is not a grant of all powers.
- 04Authorization must be enforced on the server that owns the resource, not only in the client UI.
- 05Identifiers in requests (user ids, document ids) are claims to check, not orders to obey.
- 06Session tokens and API keys are credentials for authentication. Permission logic still sits behind them.
Learning objectives
After this lesson you should be able to:
- State authentication and authorization in one sentence each and give a non-web example of both.
- Explain why hiding an Admin button in the UI is not authorization.
- Diagnose an IDOR-style failure as an authorization bug, not an authentication bug.
- Place authn and authz checks on a request path from browser cookie to database row.
- Contrast role checks with resource ownership checks and say when each fits.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Authentication asks: are you who you claim to be, at a confidence this system accepts? Passwords, passkeys, one-time codes, and SSO assertions are mechanisms for that question.
Authorization asks: may this identity do this action on this object now? Examples: read document 17, refund payment 88, list all users, deploy to production.
People blur them because both happen near login. After you sign in, the app feels open. That feeling is dangerous. The server must still ask permission on each sensitive operation.
Cookies and sessions (covered elsewhere) mainly move an authentication result across requests. They store or point to "this browser speaks for user X." They do not replace a policy that says user X may edit only X's notes.
Formal shape
Authentication factors are often grouped as something you know, have, or are. Multi-factor authentication raises confidence against stolen single factors. Confidence is never infinite. Threat models set how much is enough.
After authentication, systems create a security context: a principal (user id, service identity) plus attributes (roles, groups, tenant id). Authorization policies evaluate that context against an action and a resource.
Common policy styles include access control lists, roles (RBAC), and attributes (ABAC). Ownership checks ("resource.owner == principal.id") are frequent in multi-user apps. Role checks ("principal has admin") fit coarse powers. Many real systems need both.
On the web, a request may arrive with a session cookie. The server authenticates the session (valid, not expired, not revoked), loads the principal, then authorizes the route and object. Skipping the last step yields broken access control, a top OWASP risk class.
API tokens and keys follow the same split. Presenting a valid key authenticates a caller. Scopes and server-side policies authorize which endpoints and objects that caller may touch.
Request pipeline: authn then authz
Click a stage to see how identity and permission checks separate on one request.
Loading diagram...
Select a stage to read the boundary detail.
Worked examples
Example A: notes app. Alice logs in (authentication succeeds). She requests GET /notes/42. The server loads note 42, checks owner == Alice, and returns 200 or 404/403. If the server returns any note for any logged-in user, authentication works and authorization failed.
Example B: admin panel. The UI hides Admin links for non-admins. An attacker still posts to /admin/deleteUser. If the server checks only "has session," the UI theater failed. Authorization belongs on the server.
Example C: service-to-service call. Billing service calls Inventory with a machine identity. TLS may authenticate the channel peers. The token authenticates the calling service. Inventory still authorizes whether Billing may decrement stock for that SKU.
Example D: status codes. Unauthenticated call to a private resource -> 401 with a login challenge. Authenticated user forbidden -> 403. Not advertising existence of another user's object may yield 404 by policy. These are authorization product choices layered on authentication state.
Edge cases
Confused deputy: a privileged service acts on behalf of a user but forgets to keep the user's authority limits. The service is authenticated. The effective authorization is wrong.
Horizontal versus vertical privilege issues: horizontal is accessing another peer's objects (Alice reads Bob). Vertical is accessing higher power (user acts as admin). Both are authorization failures.
Cached authz decisions: performance layers may cache "Alice can edit doc 1." If sharing settings change, stale cache becomes a bug. Treat authorization as time-sensitive state.
Public resources: authorization can allow anonymous read. That is still a policy decision, not an absence of security thinking.
Delegation and OAuth-style consent: a user authorizes a client app to act within scopes. That is authorization of a third party. The identity provider still authenticates the user. Mechanisms differ. The two questions remain.
Logging: record principal, action, resource, and decision. Without that, you cannot audit or debug authz failures.
Mental models
ID badge vs room keys
Authentication is checking the badge at the building door. Authorization is which room keys the badge unlocks.
Passport vs visa
A passport supports identity. A visa grants entry to a place for a purpose. Having a passport does not grant every visa.
Coat check ticket
A session cookie is like a coat check ticket: it points to a stored identity. It does not say you may take every coat.
Library card vs shelf access
Showing a library card gets you recognized. Borrowing a rare book still needs a policy check.
Common misconceptions
Myth
If the user logged in, they are authorized for everything in the app.
Reality
Login establishes identity. Each sensitive action still needs a permission decision.
Myth
Authorization is only for admin versus user roles.
Reality
Roles are one policy style. Many systems also check ownership, tenancy, and action type (read vs delete).
Myth
TLS authenticates the user to the application.
Reality
Typical web TLS authenticates the server to the browser. User authentication is a separate step (password, passkey, SSO).
Myth
A 401 and a 403 mean the same failure.
Reality
In common HTTP API practice, 401 means authentication is missing or failed. 403 means the identity is known but not allowed. Clients should handle them differently.
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
A logged-in user changes the id in GET /api/orders/99 to /api/orders/100 and sees another customer's order. Is this primarily an authentication failure or an authorization failure? What check was missing?
Hint: Ask whether the server knew who the caller was, then ask whether it checked that caller against order 100.
What good looks like
Authorization/IDOR. Session authn worked. Missing ownership or tenant check on the order resource.
Exercise 02
Write a request-handling checklist with three steps that separates authn from authz for DELETE /documents/:id.
Hint: Put identity establishment before permission evaluation. Put permission evaluation before the delete side effect.
What good looks like
Something like: validate session/token -> load principal -> load document and allow only if policy says delete permitted (owner or role), else 401/403.
Exercise 03
Give one real-world non-software example of authentication without authorization, and one of authorization that still needs authentication.
Hint: Authentication recognizes a person. Authorization grants a specific action.
What good looks like
e.g. showing ID at a bar but not being allowed into a private room; a visa check that still requires passport identity first.
Sources & further reading
External references. Prefer primary documents and clear explainers.
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
How identity becomes a session after login. Use it when authN must connect to ongoing request identity.
- OAuth 2.0Docs
Delegated authorization framework overview with links into the RFCs. Read it when authZ crosses app boundaries.
- WebAuthn GuideDeep dive
Practical introduction to passwordless public-key authentication. Use it when you want authN beyond passwords.