Loading...
System Design and AI Engineering, by Roni Das. 972 interactive lessons.
Start LearningThe short answerAuthentication checks who you are (a password, a passkey, a login token) and authorization checks what you are allowed to do (read this file, open the admin page), so authentication always comes first, a failed one returns 401, and a failed authorization returns 403.
AuthN: proving who you are
the ID check at the door
AuthZ: deciding what you may do
the keycard for each room
Read across a row to compare one thing. Every word that may be new is explained just below the table.
| Aspect | Authentication | Authorization |
|---|---|---|
| Question it answers | Who are you? | What are you allowed to do? |
| Order | Always first. | Always second. You cannot decide rights for an unknown caller. |
| How it works | Checks a credential: password, passkey, one-time code, certificate. | Checks rules: roles, ownership, attributes, policies. |
| How often | At login; a token or session carries the result afterwards. | On every request, for every resource and action. |
| HTTP status when it fails | 401 Unauthorized, with a WWW-Authenticate header. | 403 Forbidden. |
| What the user can change | Their credential: a new password, a new passkey. | Nothing. Only an admin or the rules can change their rights. |
| Common standards | OpenID Connect, SAML, WebAuthn (passkeys), NIST SP 800-63B. | OAuth 2.0 scopes, RBAC, ABAC (NIST SP 800-162). |
| Real example | Logging in to your bank with a password and an SMS code. | The bank letting you see your own account but not your neighbour's. |
| Typical bug | Weak passwords, no MFA, tokens that never expire. | Forgetting the check: change the id in the URL and see someone else's data. |
Real situations, and the pick we would make in each one.
This proves identity. Add MFA, and never store the password itself, only a slow hash of it.
You already know who they are. Now check their role. A missing admin role is a 403.
Being logged in is not enough. Check that invoice 1043 belongs to this user. This is the most common place apps forget.
The server can no longer trust who sent it. Return 401 so the app asks the user to log in again.
OpenID Connect tells you who the user is (authentication). OAuth scopes limit what your app may read from Google (authorization).
Machines need both checks too: prove which service is calling (for example with mTLS), then check it may call this endpoint.
we ran this, here is what happened
We wrote the smallest app we could that shows both checks. It is written in FastAPI, a Python web framework. It has two users: asha is a viewer, and ravi is a viewer and an admin.
GET /me needs only a valid token. GET /admin/reports needs a valid token and the admin role. Then we sent six real requests with curl, a command-line tool that sends web requests, and copied what came back.
Where it ran: FastAPI 0.142.2 on uvicorn, Python 3.12.14, Apple M4, macOS 15.6. Run on 4 October 2026 by scripts/labs/compare/authn_authz.sh.
def current_user(creds: HTTPAuthorizationCredentials | None = Depends(bearer)) -> dict:
"""Authentication: who is calling? No token, or a token we do not know, is a 401."""
user = USERS.get(creds.credentials) if creds else None
if user is None:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Not authenticated: send a valid token",
headers={"WWW-Authenticate": "Bearer"},
)
return user
def require_role(role: str):
"""Authorization: is this known caller allowed? A missing role is a 403."""
def check(user: dict = Depends(current_user)) -> dict:
if role not in user["roles"]:
raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, detail=f"{user['name']} lacks role '{role}'")
return user
return check$ curl http://127.0.0.1:8765/me
HTTP/1.1 401 Unauthorized
www-authenticate: Bearer
{"detail":"Not authenticated: send a valid token"}
$ curl -H 'Authorization: Bearer tok-wrong' http://127.0.0.1:8765/me
HTTP/1.1 401 Unauthorized
www-authenticate: Bearer
{"detail":"Not authenticated: send a valid token"}
$ curl -H 'Authorization: Bearer tok-asha' http://127.0.0.1:8765/me
HTTP/1.1 200 OK
{"you_are":"asha","roles":["viewer"]}
$ curl -H 'Authorization: Bearer tok-asha' http://127.0.0.1:8765/admin/reports
HTTP/1.1 403 Forbidden
{"detail":"asha lacks role 'admin'"}
$ curl -H 'Authorization: Bearer tok-ravi' http://127.0.0.1:8765/admin/reports
HTTP/1.1 200 OK
{"report":"revenue by country","for":"ravi"}
$ curl http://127.0.0.1:8765/admin/reports
HTTP/1.1 401 Unauthorized
www-authenticate: Bearer
{"detail":"Not authenticated: send a valid token"}| What we measured | Authentication | Authorization |
|---|---|---|
| No token, or a token we do not knowauthentication failed, so authorization never ran | 401 Unauthorized | never reached |
| asha (viewer) asks for /me200 OK | passes | passes |
| asha (viewer) asks for /admin/reportswe know her; she lacks the admin role | passes | 403 Forbidden |
| ravi (admin) asks for /admin/reports200 OK | passes | passes |
What this shows
The last request is the one to remember. With no token, /admin/reports returned 401, not 403. The app could not ask "is this person an admin?" before it knew who the person was. Who you are always comes first.
What this test does not show: The tokens are fixed strings so the code stays short. A real app would check a signed JWT or a session cookie, with expiry. The 401 and 403 decisions stay exactly the same. The script is scripts/labs/compare/authn_authz.sh in our repository.
Returning 403 when the user is not logged in.
Send 401 with a WWW-Authenticate header, as RFC 9110 requires. The client then knows to log in, not to give up.
Checking only that the user is logged in.
Logged in is not allowed. Check ownership on every object: does invoice 1043 belong to this user? OWASP calls this validating permissions on every request.
Hiding the admin button and calling it security.
The browser is not a lock. Anyone can send the request with curl, like we did. The check must run on the server.
Allowing by default.
OWASP's advice is deny by default: if no rule says yes, the answer is no. New endpoints then start safe.
Treating OAuth 2.0 as a login system.
OAuth 2.0 grants access to an API. To know who the user is, use OpenID Connect on top of it.
Putting roles in a token that never expires.
A removed admin keeps admin rights until the token dies. Keep access tokens short-lived and re-check important rights on the server.
AuthN is short for authentication: proving who you are. AuthZ is short for authorization: deciding what you may do. AuthN comes first; AuthZ uses its answer.
Authorization. OAuth 2.0 lets an app get limited access to an API for a user, through scopes such as read:calendar. OpenID Connect adds an ID token on top of OAuth 2.0, and that adds authentication.
A one-time password (OTP), such as a 6-digit code from an app or an SMS, is authentication. It proves you hold a phone or app. It is often the second factor in MFA. Banks also use OTPs to confirm a payment, but the code itself still proves who you are.
It is a historical naming mistake. RFC 9110 defines 401 as a request that lacks valid authentication credentials, and 403 as a request the server understood but refuses. Read 401 as unauthenticated.
People usually mean three ways to write the rules: role-based (RBAC, rights come from your role), attribute-based (ABAC, rights come from facts like department or time, described in NIST SP 800-162), and relationship-based (ReBAC, rights come from links such as owner of this document).
The same split. In AWS, Google Cloud or Azure, an identity service first authenticates a user or a program. Then access policies (IAM, identity and access management) decide which resources that identity may touch.
From the System Design course, in the order we would read them.
Primary sources only: standards, vendor docs and our own runs. Each one shows its date and the day we opened it.
Authentication vs Authorization is one row in a much bigger table. Our System Design course has 769 lessons on networks, databases, caching, scaling, messaging, security and reliability, each drawn step by step, so you can explain the trade-off in an interview and pick right at work. 18 lessons are free to read, with no card needed.
the hands-on parts are real runs, like this one
course 1
From absolute beginner to principal engineer, drawn step by step.