Authentication vs Authorization

Authentication vs Authorization

These two words sound alike, get abbreviated to the same three letters (authn and authz), and live next to each other in every login flow — so people conflate them constantly. But they answer two different questions, and confusing them is the root cause of a huge fraction of real-world security breaches.

Authentication (authn) asks: "Who are you, and can you prove it?" It establishes identity. When you type a username and password, tap a fingerprint sensor, or click a magic link in your email, you are authenticating.

Authorization (authz) asks: "Now that I know who you are, what are you allowed to do?" It establishes permissions. Being logged in as alice@corp.com does not mean you can delete the production database or read another user's medical records — that is a separate decision.

The mental model: authentication is showing your passport at the airport (proving you are who you claim). Authorization is the boarding pass and visa that decide which gate, which plane, and which country you may actually enter. One identity, many different permission decisions.

How it works, precisely

Authentication verifies a credential against something the system trusts. The classic taxonomy is three factors: something you know (password, PIN), something you have (phone, hardware key, TOTP app), and something you are (fingerprint, face). Requiring two different factors is MFA. The output of successful authn is a proven principal — an identity the rest of the system can rely on. That identity is usually persisted as a session (a server-side record keyed by a cookie) or a token (a signed JWT the client carries and the server verifies statelessly).

Authorization takes that established identity plus the requested action and resource, and evaluates a policy to return allow/deny. The dominant models:

• ACL (Access Control List): a direct per-resource list of who may do what ("doc #4471: alice=read, bob=write"). Simplest, but does not scale to inherited or shared membership.
• RBAC (Role-Based Access Control): permissions attach to roles (admin, editor, viewer); users get roles. Simple, coarse-grained.
• ABAC (Attribute-Based): decisions use attributes of the user, resource, and context (e.g. user.dept == doc.dept AND time < 18:00). Fine-grained, expressive.
• ReBAC (Relationship-Based): permissions follow relationships in a graph ("you can edit a doc if you own the folder it lives in") — the Google Zanzibar model.
• PBAC (Policy-Based Access Control): standalone policies evaluated by a dedicated engine (OPA, AWS IAM). Most expressive and audit-friendly, but adds a policy-language complexity.

The critical ordering rule: authn always precedes authz. You cannot decide what an identity may do before you have established the identity. HTTP encodes the distinction directly: 401 Unauthorized actually means unauthenticated ("log in first"), while 403 Forbidden means authenticated but not authorized ("I know who you are; you still can't do this").

Worked scenario: a document API at scale

Imagine a SaaS docs product serving 50,000 QPS at peak. A user opens GET /docs/9812. Two distinct checks happen on that single request:

1. Authn (once per session, cached thereafter). The browser sends a cookie carrying a JWT. The API verifies the signature with the identity provider's public key. Signature verification is pure CPU — roughly 50–200 µs — with no network hop, which is exactly why stateless tokens scale: at 50k QPS you are not hitting a session store 50,000 times a second. The token's exp claim (say 15 minutes) bounds its lifetime; a refresh token silently mints a new one.

2. Authz (every single request). Now the service must decide: may alice read this specific doc 9812? With ReBAC (Zanzibar-style), it queries a permissions service: "does alice have viewer on doc:9812?" That is a graph lookup — Google's Zanzibar paper (Pang et al., USENIX ATC 2019) reports serving roughly 10 million authorization QPS at <10 ms p95 globally, thanks to aggressive caching of relationship tuples. With plain RBAC the check is often local ("is alice's role in {viewer, editor, admin}?") and takes microseconds, but it cannot express "only her docs."

The load asymmetry is the key insight: you authenticate a user once and reuse that identity for millions of requests, but you authorize every request — so the authz path is the one you optimize, cache, and worry about under load.

Trade-offs — when to use which, and which alternative

These are not competing choices; you always need both. The real trade-off decisions are within each half:

Sessions vs stateless tokens (an authn choice). Server-side sessions are trivially revocable — delete the row and the user is instantly logged out — but every request costs a session-store lookup. JWTs are self-contained and cheap to verify at massive scale, but hard to revoke before expiry: a stolen token is valid until exp. Use sessions when instant revocation matters (banking, admin consoles) or traffic is modest. Use JWTs for high-throughput, multi-service, or mobile APIs where a per-request DB hit would dominate cost — and keep expiry short (5–15 min) to bound the blast radius.

ACL vs RBAC vs ABAC vs ReBAC vs PBAC (an authz choice). Use ACL for tiny per-resource guest lists where the owner is obvious ("who can see this doc?"). Use RBAC when permissions are coarse and stable (a handful of roles) — it is the simplest thing that works and is trivially auditable. Reach for ABAC when decisions depend on context or resource attributes (region, time, data classification) and RBAC would explode into a combinatorial mess of roles ("role explosion"). Reach for ReBAC when the core question is ownership/sharing in a graph — Google Docs sharing, GitHub repo access, folder inheritance — where relationships, not static roles, define access. Reach for PBAC when rules must be versioned, centrally authored, and applied consistently across services (OPA, AWS IAM). Don't reach for ABAC/ReBAC/PBAC prematurely: they add a policy engine and operational surface you must run and reason about.

Pitfalls an interviewer probes

• "401 vs 403 — which is which?" Naming trap: 401 Unauthorized = not authenticated; 403 Forbidden = authenticated but not authorized. Getting this backwards signals you haven't internalized the split.
• Broken Object-Level Authorization (BOLA/IDOR). The #1 API vulnerability. The endpoint authenticates the caller but forgets to check they own the object: GET /invoices/1005 works, so the attacker just tries 1006. Authn was fine; authz was skipped. See the exact shape of the bug below.
• BOLA, before and after. The vulnerable data access looks like this: if (token.isValid()) return db.query("SELECT * FROM invoices WHERE id = ?", request.id) — it authenticates the caller (valid signature, unexpired token) but never checks ownership, so nothing ties invoice 1006 to this caller, and swapping 1005 → 1006 returns another user's invoice. The fix scopes the query by an identity read from the verified token: db.query("SELECT * FROM invoices WHERE id = ? AND owner_id = ?", request.id, token.sub) — and a zero-row result becomes 404 (or 403), never someone else's 200. The one-liner: the scoping key (owner_id = token.sub) must come from the token the server verified, never from a client-supplied ID — authorize the specific object against the token's identity on every request.
• Trusting the client for authz. Hiding an "admin" button in the UI is not authorization — the server must enforce it. Client-side checks are UX, not security.
• Confused deputy / privilege escalation. A service acting on a user's behalf uses its own elevated permissions instead of the user's, letting a low-privilege user reach high-privilege actions. Always propagate the caller's identity, not the service's.
• JWT revocation. "How do you log someone out immediately with stateless JWTs?" You can't purely — you need short expiry plus a revocation/denylist or a session component. Claiming JWTs are freely revocable is a red flag.

Key takeaways

• Two different questions: authn proves who you are (identity); authz decides what you may do (permissions). Authn always runs first.
• Load asymmetry drives design: you authenticate roughly once per session but authorize every request — so authz is the hot path to cache and scale, and tokens vs sessions trade revocability against per-request cost.
• Pick the authz model to fit the shape of access: ACL for tiny per-resource lists, RBAC for coarse stable roles, ABAC for context/attribute-driven rules, ReBAC for ownership-and-sharing graphs, PBAC for cross-service versioned policies — and resist over-engineering early.
• Most breaches are missing authz, not broken authn: BOLA/IDOR, client-trusted checks, and confused-deputy bugs all come from verifying identity but never verifying access to the specific resource.

In the worked scenario, after the gateway validates the user's identity, it forwards the request context to an OPA sidecar; OPA evaluates the Rego policy and returns allow/deny before the request ever reaches the order service.