CYBER-04-001-P · Primer — Authentication vs Authorization: Who You Are vs What You Can Do

The idea in one sentence

Authentication proves who you are ("this really is Priya"), and authorization decides what that proven identity is allowed to do ("Priya may read this file but not delete it") — they are two different questions, answered by two different mechanisms, in that fixed order, and almost every access-control bug in the world is one of them silently standing in for the other.

Why it exists

Picture a nightclub. At the door, a bouncer checks your ID against your face — that's authentication: are you the person you claim to be? Inside, a different rule governs whether you can walk into the VIP room — that's authorization: given who you are, are you permitted to do this specific thing? The bouncer proving your identity says nothing about whether you're on the VIP list. Confusing the two is how someone with a perfectly valid ID ends up somewhere they were never supposed to be.

Software runs into this every second. A request arrives at your server. Before you do anything with it, you have to settle two separate facts:

• Who is this? An unauthenticated request is a stranger — you can't make any decision about a caller whose identity you haven't established.
• May they do this? Even a fully identified user is not allowed to do everything. Being logged in as yourself does not entitle you to read someone else's medical records.

The reason we insist on naming these as two ideas — rather than one fuzzy notion of "logging in" — is that they fail independently and they fail differently. Get authentication wrong and impostors get in. Get authorization wrong and legitimate users reach data and actions that aren't theirs. The second kind of bug is the more common and often the more damaging, precisely because the person is genuinely who they say they are — every audit log shows a real, "successful" login — and the system still handed them something it shouldn't have. Keeping the two questions distinct is what lets you reason about, test, and secure each one on its own.

How it works

Four pieces, in order. The order matters: you can't authorize a caller you haven't authenticated.

1. Authentication (authN) — establishing identity. The system challenges the caller to prove they are who they claim, and it does so by asking for one or more factors, which NIST SP 800-63B groups into three families: something you know (a password or PIN), something you have (a phone, a hardware security key, a one-time code), and something you are (a fingerprint, a face). A password alone is a single factor; combining two families is multi-factor authentication (MFA), which is strong because an attacker must steal two different kinds of thing. Crucially, authentication's only job is to answer "who?" — it produces an established identity, and it produces nothing else. It does not decide what you may do. The output of a successful authentication is typically a session or a token the caller carries on later requests so they don't re-prove identity every time.

2. Authorization (authZ) — deciding entitlement. Now that the system knows who the caller is, a separate mechanism decides what that identity may do. This is a lookup against the caller's entitlements — their permissions. Two common models: RBAC (role-based access control), where permissions attach to roles like editor or admin and users are granted roles; and ABAC (attribute-based access control, defined in NIST SP 800-162), where the decision is computed from attributes of the user, the resource, and the context ("a nurse may read a chart only for a patient in their assigned ward, during their shift"). Either way, authorization takes the authenticated identity as an input and returns a permit-or-deny verdict for a specific action on a specific resource.

3. Identity vs entitlement — the line that everything else in this course is built on. This is the conceptual spine. Identity is a stable fact about who someone is: Priya is Priya whether she's an admin or a guest. Entitlement is a mutable fact about what she may do: her permissions can be granted this morning and revoked this afternoon without her identity changing at all. Keeping them separate is powerful — you can promote, demote, or fire someone by changing their entitlements while their identity stays constant, and you can rotate their password (part of proving identity) without touching a single permission. Every later topic in IAM & Zero Trust is one side of this split: single sign-on, MFA, and federation are all authentication; roles, policies, least privilege, and access reviews are all authorization.

4. The access decision — where the two meet. Every protected request runs the same two-step gate. First an authentication step turns the incoming credential or token into an identity (or rejects it). Then an authorization step takes that identity plus the requested action and returns allow or deny. HTTP even gives you two distinct status codes for the two distinct failures, defined in RFC 9110: 401 Unauthorized means "I don't know who you are — authenticate first" (an authN failure, despite the confusing name), and 403 Forbidden means "I know exactly who you are, and you may not do this" (an authZ failure). On the web this often spans systems: protocols like OAuth 2.0 (RFC 6749) and OpenID Connect exist precisely to carry a proven identity and a set of granted scopes from one service to another, packaged in tokens such as JWTs (RFC 7519) — but the two questions inside are always the same two.

The one gotcha

Authentication is not authorization — and the classic breach is a system that authenticates flawlessly and then forgets to authorize at all. The trap is assuming that because a request came from a logged-in user, it must be a permitted request. It is not. The most common web vulnerability in this family is broken object-level authorization (often called IDOR — insecure direct object reference): the app checks that you're logged in, then serves whatever record ID you ask for — /api/invoices/1001 — without ever checking that invoice 1001 is yours. You change the number to 1002 and read a stranger's invoice. You were perfectly authenticated the entire time; nobody ran the second check. The identity gate was closed and the entitlement gate was wide open.

The mirror-image mistake is just as real: leaning on an identity check to stand in for a permission check ("only admins know this URL, so we don't need to verify roles"). Obscurity is not authorization. The discipline that prevents both failures is to treat every protected action as needing its own explicit answer to "may this identity do this thing to this resource?" — computed fresh, on the server, on every request. A valid login is the beginning of the access decision, never the end of it.

See it — one request through the two gates

flowchart TD
    R["Request arrives<br/>with a credential<br/>or token"] --> A{"AuthN: can we<br/>prove who this is?"}
    A -- "no / bad token" --> N["401 Unauthorized<br/>we don't know you<br/>(prove identity)"]
    A -- "yes, identity known" --> Z{"AuthZ: may THIS<br/>identity do THIS<br/>to THIS resource?"}
    Z -- "not entitled" --> F["403 Forbidden<br/>we know you, but<br/>you may not"]
    Z -- "entitled" --> OK["Allow: perform<br/>the action"]

The one-line takeaway

Authentication answers who you are and authorization answers what you may do — they are two separate checks in a fixed order, and safe systems prove identity first and then, on every single request, decide entitlement explicitly rather than assuming a logged-in user is a permitted one.

Where you'll meet it

You'll meet this split on your very first login screen and never stop meeting it. The instant you wire up "sign in with Google," you're doing authentication — and the instant you write if user.role == 'admin', you've crossed into authorization. You'll meet the gotcha the first time a security review or a bug report shows that changing an ID in a URL leaks someone else's data, and you'll learn to add the ownership check you forgot. You'll meet the two HTTP codes debugging an API — 401 when a token is missing or expired (fix the credential), 403 when it's valid but lacks the scope (fix the permissions) — and knowing which is which tells you which gate failed. In interviews it surfaces constantly: "what's the difference between authentication and authorization?" (identity vs entitlement, in that order), "what does 401 vs 403 mean?" (unknown caller vs known-but-forbidden caller), and "how would you prevent a user from reading another user's records?" (authorize every object access on the server, per request, not just at the door). The habit to build, and the frame for everything else in this course: authenticate once to establish who, then authorize every action to decide what — and never let the first check quietly answer for the second.

Named concepts: authentication (authN), authorization (authZ), identity vs entitlement, the access decision