Authentication and authorization — proving identity and granting access

"Authentication" and "authorization" both start with "Auth" in English, and in Japanese they differ by only a single character. Designing with them blurred creates a system where anyone who has logged in can do anything.

The criterion for separating them is simple. Confirming who you are is authentication; deciding what to allow is authorization.

What you'll learn in this chapter

• The difference, and why authentication always comes first
• The difference in status codes returned on failure
• Whether to hold auth state in a session or a token
• Where authorization should be checked

Prerequisites

Builds on the status code classification from HTTP.

What this chapter does not cover

Implementation details and the database design angle are covered by existing guides.

Topic	See
Table design, password storage, MFA, audit logs	Database Design Guide — Designing an authn/authz system
Federation with external services	Database Design Guide — OAuth and OpenID Connect
Where to put a token	Browser storage
Implementing token storage and sessions in SPAs	React Guide — SPA authentication
Framework-level implementation	Laravel API Development Guide — Authentication / Authorization

Authentication and authorization

	Authentication	Authorization
Question	Who are you	Are you allowed to do that
What's verified	Identity	Permission
Examples	Login, fingerprint, one-time password	Only admins can delete, users see only their own orders
On failure	401 Unauthorized	403 Forbidden
Order	First	After

The order is never reversed. You cannot decide what to allow for someone whose identity is unknown.

Anonymous access looks like an exception. On a site where public pages are visible without logging in, authentication seems skipped — but in reality, authorization is being decided against the identity "anonymous". The rule "anonymous is allowed to view" is authorization at work.

The difference in status codes

The confusing part is the name of 401. Written as Unauthorized, its meaning is unauthenticated. That's a historical quirk in the spec. The practical split is as follows. The full classification of status codes is in HTTP.

Code	Situation	What the client should do
401 Unauthorized	Credentials absent, expired, or invalid	Re-authenticate
403 Forbidden	Authenticated, but permission is insufficient	Give up. Retrying won't help

401 says "reauth might get you through"; 403 says "reauth won't". If you remember them by that contrast, they don't get confused.

The three authentication factors

Materials for verifying identity divide broadly into three categories.

Factor	Content	Examples	Weakness
Knowledge (Something you know)	Something only the person knows	Password, PIN	Leaks, guesses, reuse
Possession (Something you have)	Something only the person holds	Smartphone, hardware key	Theft, loss
Inherence (Something you are)	The person's physical traits	Fingerprint, face, iris	Can't be changed, has false positives

Multi-factor authentication (MFA) means combining two or more different factors. Here's where people get it wrong: "password + secret question" is not multi-factor, because both are knowledge. They break together over the same leak.

"Password + code sent to a smartphone" combines knowledge and possession, so it's multi-factor. If the password leaks, without the device it still can't be breached.

How to carry auth state

HTTP is stateless, so after logging in once, the next request is back to "unknown who". You need to indicate on every request that you're already authenticated.

	Session	Token
What's passed	A session ID (an opaque string)	A signed token (contains information)
Where state lives	On the server (session store)	In the token itself
Invalidation	Immediate — remove it from the store	Can't be stopped until it expires
Sharing across servers	Requires shared store	Only the verification key is needed
Main transport	Cookies	Authorization header, or cookies

The axis of choice is immediate invalidation vs. scaling.

Sessions keep state server-side, so you can invalidate immediately. "Stop this suspected account right now" is reliable.

Tokens keep the server stateless, so horizontal scaling is easier. In exchange, once issued, a token is valid until it expires. That expiry is expressed as an instant. Holding it in local time makes the expiry drift depending on the interpreting time zone (Datetimes and time zones). To mitigate, designs combine a short-lived access token with a long-lived refresh token and a separate revocation list.

Authorization models

Several patterns exist for expressing permissions.

Model	Idea	Fits when
RBAC (role-based)	Assign roles to users, tie permissions to roles	Organizational titles map to permissions
ABAC (attribute-based)	Decide from attributes of user, resource, situation	Context matters ("only their own department")
ACL (access control list)	List per resource who can do what	Per-item specifications like file sharing

In practice, they mix. "Admin role sees everything; regular users see only their own" is RBAC + ABAC.

Authorization is decided server-side

Hiding a button in the UI is not authorization.

// This isn't authorization; it's UI cleanup
{user.role === 'admin' && <DeleteButton />}

Hiding the button doesn't stop calling the API directly. Anyone can craft a request from the browser dev tools. Authorization must be decided server-side; client-side rendering choices are helpers for the user experience.

OWASP Top 10:2025 lists A01 as Broken Access Control. Typical shapes:

• Rewriting an ID in the URL reveals someone else's data (change /orders/1001 to /orders/1002)
• No authorization check on admin APIs
• Permission is judged only on the client

The first is especially frequent, and the ownership match between the resource and the operator must be checked server-side.

How to structure a written answer

When asked "how are authentication and authorization different", here's how to build the answer.

1. Define each in one sentence — authentication verifies identity; authorization decides permission
2. State the ordering — authentication first, authorization after. You can't decide permissions for someone unknown
3. A concrete pair — "Badging in to the building is authentication; which rooms you can enter based on your title is authorization" — use a familiar pair
4. Touch the technical realization — on failure, the status codes split as 401 vs. 403
5. One implementation note — authorization is decided server-side. UI hiding isn't authorization

With the third example present, it reads as understanding rather than memorization. The basics are satisfied by 1–3, so stop there when time or word count is tight.

Common misconceptions

"401 means 'no permission'." — 401 is unauthenticated. Insufficient permission is 403. The name Unauthorized is misleading, but the practical split follows authn vs. authz.

"Password + secret question is multi-factor." — Both are knowledge factors, so it isn't multi-factor. Different factors must be combined.

"If you can log in, you're already authorized." — Different. Login only pins down "who". What that person is allowed is decided separately.

"Only admins see the button, so it's safe." — Display control isn't authorization. Direct API calls go through.

"With JWT, logout takes effect immediately." — With tokens, you can't stop them until expiry as a rule. To stop immediately, add a revocation list.

Exercises

Q1. Are the following authentication or authorization?

A. Verifying a one-time password
B. Confirming "is this order mine"
C. Verifying a password hash
D. Confirming "does this user have the admin role"
E. Reading a fingerprint

Answer and explanation

Answers:

	Class	Why
A	Authentication	Verifying identity via a possession factor
B	Authorization	Identity is known; deciding permission on the resource
C	Authentication	Verifying identity via a knowledge factor
D	Authorization	Deciding permission
E	Authentication	Verifying identity via an inherence factor

The distinguishing question is "is it checking who you are, or whether you may". A / C / E verify identity; B / D decide permission afterward.

B is an authorization case people miss. Assuming "logged in means it's mine" leaves the door open to rewriting IDs and seeing other people's orders.

Q2. An API returned 403 Forbidden. Should the client route to the login screen?

Answer and explanation

Answer: It should not.

403 means "we know who you are, but you don't have permission to do that". Reauthenticating as the same user changes nothing. Sending them to login makes them hit the same error every time.

The correct response is to say permission is missing and offer a different path.

Code	Response
401	Login screen. Try token refresh
403	Show "no permission". Offer a request-access flow if there is one

Conversely, if an API returns 403 for an expired token, the client cannot tell whether reauth is called for. Returning these two correctly is a server-side prerequisite.

Q3. In an interview: "How do authentication and authorization differ?" Answer in three sentences.

Answer and explanation

Sample answer:

Authentication is the process of verifying that a person is who they claim to be, using materials like a password or biometrics to establish identity. Authorization is the process of deciding whether that person may perform a given operation, using roles or ownership to determine permission. Authentication comes first and authorization comes second, because you can't decide what to allow for someone whose identity is unknown.

Mapping of what's included:

Sentence	Elements
1	Definition of authentication + example means
2	Definition of authorization + example criteria
3	Ordering + reason

If you have room, adding "on failure, authentication returns 401 and authorization returns 403" shows technical understanding too. Conversely, just two definition sentences don't distinguish memorization from understanding. The dividing line is whether ordering and its reason are in there.

Summary

• Authentication verifies "who"; authorization decides "what is allowed"
• Authentication first, authorization after. The order is never reversed
• On failure, authentication is 401, authorization is 403. 401 says "reauth may help"; 403 says it won't
• Authentication factors are knowledge / possession / inherence. MFA is a combination of different factors; stacking two of the same factor isn't multi-factor
• Sessions can be invalidated immediately; tokens scale more easily. Tokens can't be stopped until they expire as a rule
• Permissions are expressed as RBAC (roles), ABAC (attributes), or ACL (enumeration). In practice they mix
• Authorization is decided server-side. UI hiding isn't authorization
• OWASP Top 10:2025 A01 is Broken Access Control

Related references

• Database Design Guide — Designing an authn/authz system — Design of password storage, sessions, MFA, and audit logs
• Database Design Guide — OAuth and OpenID Connect — Federation with external services
• Browser storage — Where to put a token
• React Guide — SPA authentication — Implementing XSS/CSRF countermeasures in an SPA
• OWASP Top 10:2025

What to read next

• Common web attacks and defenses — Why access-control failures rank #1 in the Top 10, and other attacks