Authorization

Authentication (AuthN) answers who are you → it verifies identity (password, OAuth, token). Authorization (AuthZ) answers what may you do → it runs on every request after.

Cause → effect: the token proved identity (AuthN OK), but when the system mapped user 42 → action DELETE → resource order 99, it found no matching permission → returns 403 (not 401; 401 means "not authenticated / log in", 403 means "authenticated but not allowed").

• Run frequency: AuthN happens at the session boundary (login / token issuance); AuthZ runs ~every request (a single page can fire 20+ checks).
• Trade-off / cost: because AuthZ runs constantly, its latency is multiplied across every call — a 5 ms permission lookup on a request that does 8 checks adds 40 ms before any real work. That is why people cache it (later steps), and why mixing the two concerns into one slow "login check" is a design smell.

RBAC (Role-Based Access Control) inserts a role between users and permissions: user → role → permission. You assign permissions to roles, and users to roles.

Mechanism of one check for can(user42, delete, order99):

• 1. Look up user 42's roles → {editor, billing}.
• 2. Expand roles to permissions → {order:read, order:write, ...}.
• 3. Test if order:delete is in that set → not present → deny.

Cause → effect: grant a new permission to 5,000 support agents by editing 1 role, not 5,000 user rows — the role is the single point of change.

Trade-off / cost: RBAC is coarse — a role is the same for everyone who holds it, so it can't express "only orders YOU created" or "only during business hours" without baking the condition into the role name. Teams work around this by minting hyper-specific roles (editor_region_eu_readonly) and end up with role explosion — hundreds of near-duplicate roles that nobody can audit. When you hear "it depends on the resource's attributes," RBAC alone is the wrong tool.

ABAC (Attribute-Based Access Control) decides via a policy/rule evaluated at request time over attributes of the subject, resource, action, and environment — not pre-assigned roles.

Mechanism — the policy engine evaluates a boolean expression:

• subject.dept == resource.dept AND
• resource.locked == false AND
• 9 <= env.hour < 17 → all true → allow.

Cause → effect: one rule replaces the combinatorial explosion of roles — when a new department appears, the rule subject.dept == resource.dept still holds with zero new roles.

Trade-off / cost: (1) the engine must gather every attribute at decision time — resource.dept and resource.locked may require a DB fetch, adding latency and coupling AuthZ to your data; (2) it's hard to answer "who can access X?" — there is no membership list to read, so you'd have to run every user through the policy, whereas RBAC just lists the role's members. RBAC = easy to audit, coarse; ABAC = expressive, hard to audit. Many systems combine them: RBAC for the broad gate, ABAC for the fine condition.

ReBAC (Relationship-Based Access Control) stores access as a graph of relationship tuples shaped object#relation@subject, e.g. doc:99#viewer@user:42 or doc:99#parent@folder:7.

Mechanism — a check is a graph reachability search: starting from doc:99#viewer, can I reach user:42 by walking edges (direct share → group membership → inherited folder permission)? If a path exists → allow.

Cause → effect: inheritance ("folder → all docs inside") is expressed once as a single parent edge, instead of duplicating a viewer tuple onto every child doc.

• Scale signal: Google's Zanzibar handles trillions of relationship tuples at p95 < 10 ms, with in-memory caches absorbing ~90%+ of reads (the source of that low latency).
• Trade-off / cost: a check can require multiple sequential graph hops, each potentially its own lookup — deep nesting blows up tail latency, so you need aggressive caching plus consistency tokens ("zookies") that pin the check to a snapshot at least as fresh as the content. Without that you hit the "new enemy" problem — honoring a stale cached ACL and granting access that was already revoked. It's the most powerful model and the most operationally heavy — overkill unless your domain is genuinely graph-shaped (sharing, hierarchies, social).

Two layers, two jobs:

• Gateway / edge: good for coarse checks (is the token valid? does this role even reach this route?). Cheap, central, blocks obvious junk early.
• Service-level: required for fine-grained, data-dependent checks ("is this your order?") because only the service knows the resource's attributes.

Cause → effect of gateway-only: a caller that reaches a service directly (an internal/compromised neighbor service, a misrouted internal call, SSRF) skips the edge entirely → no check runs → data leak. This is why zero-trust / defense-in-depth says the service must not assume the gateway already checked.

Trade-off / cost: enforcing in every service means (1) every team re-implements AuthZ → drift and inconsistent bugs, and (2) duplicated lookup latency. The standard fix is the PDP/PEP split: a centralized Policy Decision Point owns the policy logic, while a local Policy Enforcement Point at each service does the blocking — implemented as a sidecar or library (e.g. an OPA agent, or a Zanzibar-style check service). Policy stays central and consistent; enforcement stays local and unbypassable.

Mechanism: a JWT is a signed, self-contained token carrying claims (e.g. roles:[admin], exp:...). The service verifies the signature with the issuer's key and reads the claims — no network call, no DB hit → fast, stateless AuthZ.

Cause → effect of the bug: the token issued at login still physically contains roles:[admin]. Revoking the role updated the database, but the service trusts the self-contained token, not the DB → the stale claim is honored until the token expires. With a 1-hour TTL, a token minted at 09:45 stays valid until ~10:45 — the fired admin keeps power for the remainder of that window.

This is the core trade-off: statelessness vs. revocation latency.

• Long TTL (hours): fewer re-auth round-trips, but a large revocation window.
• Short TTL (5–15 min) + refresh token: small window (revocation takes effect at the next refresh), but more traffic to the auth server.
• Token denylist / introspection: near-instant revocation, but you've reintroduced the central lookup the JWT existed to avoid — back to stateful.

Interview line: "JWTs trade revocation immediacy for statelessness; I'd use short-lived access tokens with refresh, and a denylist only for emergency revocation."

They operate at different layers, so "OAuth vs JWT" is like "HTTP vs JSON" — not alternatives.

• OAuth 2.0 = an authorization framework (a protocol). It defines the flow by which an app gets delegated access to a resource on a user's behalf without seeing their password — who issues tokens, how they're scoped, refreshed, and revoked. It does not mandate a token format.
• JWT = a token format. A signed, self-contained way to package claims (RFC 7519). It says nothing about how the token was obtained.
• OIDC (OpenID Connect) = an identity layer on top of OAuth 2.0. OAuth alone only proves "this app may call this API," not who the user is; OIDC adds that by issuing an ID token (a JWT) with verified identity claims.

Cause → effect: they compose, they don't compete. A typical setup runs the OAuth flow to obtain a token, has the authorization server format that token as a JWT, and uses OIDC when it also needs authenticated identity. Saying "OAuth instead of JWT" reveals the confusion: OAuth is the how-you-get-it, JWT is the what-it-looks-like.

Trade-off / cost: the choice that does trade off is JWT (self-contained) vs. an opaque token (a random string the resource server must introspect against the auth server). JWT = fast local verification, but the revocation-lag problem from the previous step; opaque = instant revocation by central lookup, at the cost of a network round-trip per check. OAuth supports either format.