Security Comparison
Authentication vs Authorization
Authentication proves who you are; authorization decides what you may do. Authentication happens once, at the start of a session; authorization is checked on every request that touches something protected. Confusing them is a leading cause of real breaches — a logged-in user is not the same as a user permitted to see this record.
The short answer
Authentication answers "who are you"; authorization answers "may you". Authenticate once, authorize on every single request — including the ones the UI does not offer.
When to choose each
Choose Authentication
Proving who you are.
- Verifying identity — passwords, passkeys, MFA, SSO
- Issuing a session or a token once identity is established
- Answering "is this really Alice?"
- The failure response is 401 Unauthorized
Choose Authorization
Deciding what you are allowed to do.
- Checking permissions, roles and ownership
- Enforcing rules on every request, not just at login
- Answering "may Alice delete this invoice?"
- The failure response is 403 Forbidden
Authentication vs Authorization: side by side
10 dimensions. A highlighted cell means one side is clearly ahead on that specific point — most rows are trade-offs and score neither.
| Dimension | Authentication | Authorization |
|---|---|---|
| The question it answers | "Who are you?" | "Are you allowed to do this?" |
| Short name | AuthN | AuthZ |
| When it happens | Once, at the start of a session. | On every single request that touches something protected. |
| What it checks | Credentials — password, passkey, OTP, certificate, identity provider assertion. | Roles, permissions, ownership and policy against the specific resource. |
| HTTP status on failure | 401 Unauthorized — despite the name, this is about authentication. | 403 Forbidden — you are known, and still not permitted. |
| Can the user fix it? | Yes, usually by logging in correctly. | No. Retrying with the same identity changes nothing. |
| Typical mechanisms | Sessions, JWTs, OAuth/OIDC, SAML, MFA, passkeys. | RBAC, ABAC, ACLs, policy engines, ownership checks in the query. |
| Order | First — you cannot decide permissions for an unknown party. | Second, and repeatedly thereafter. |
| Common failure | Weak password storage, missing MFA, tokens that never expire. | Broken object level authorization — changing an ID in the URL returns another user's data. |
| Where it must live | Server-side, always. | Server-side, always — hiding a button in the UI is not access control. |
The question it answers
Authentication
"Who are you?"
Authorization
"Are you allowed to do this?"
Short name
Authentication
AuthN
Authorization
AuthZ
When it happens
Authentication
Once, at the start of a session.
Authorization
On every single request that touches something protected.
What it checks
Authentication
Credentials — password, passkey, OTP, certificate, identity provider assertion.
Authorization
Roles, permissions, ownership and policy against the specific resource.
HTTP status on failure
Authentication
401 Unauthorized — despite the name, this is about authentication.
Authorization
403 Forbidden — you are known, and still not permitted.
Can the user fix it?
Authentication
Yes, usually by logging in correctly.
Authorization
No. Retrying with the same identity changes nothing.
Typical mechanisms
Authentication
Sessions, JWTs, OAuth/OIDC, SAML, MFA, passkeys.
Authorization
RBAC, ABAC, ACLs, policy engines, ownership checks in the query.
Order
Authentication
First — you cannot decide permissions for an unknown party.
Authorization
Second, and repeatedly thereafter.
Common failure
Authentication
Weak password storage, missing MFA, tokens that never expire.
Authorization
Broken object level authorization — changing an ID in the URL returns another user's data.
Where it must live
Authentication
Server-side, always.
Authorization
Server-side, always — hiding a button in the UI is not access control.
Frequently Asked Questions
What is the difference between 401 and 403?
401 Unauthorized means authentication is missing or failed — logging in could fix it, and the response should say how via WWW-Authenticate. 403 Forbidden means you are authenticated and still not allowed; authenticating again changes nothing. The 401 name is a historical misnomer: it is about authentication despite saying "unauthorized".
What is broken object level authorization?
Checking that someone is logged in but not that this particular record belongs to them — so changing an ID in the URL returns someone else's data. It is consistently at the top of the OWASP API Security list, because the authentication looks correct and the bug is entirely in the missing ownership check.
Does a JWT handle authorization?
It can carry claims about roles, but the decision is still yours to make and enforce server-side on every request. A token that says `role: admin` is only meaningful if your code verifies the signature and then actually checks the claim. Trusting an unverified token is the same as having no auth at all.
Is hiding a button authorization?
No. Hiding UI is a usability choice, not a security control — anyone can call the API directly with curl. Every action must be authorized on the server, whether or not the interface offers it.