What is Authorization

What is Authorization

Once a system knows who you are, it still has to decide what you are allowed to do. That second decision is authorization. Authentication answers "are you really Alice?"; authorization answers "may Alice delete this invoice?" They are almost always confused in interviews, and getting the distinction crisp is the single fastest way to sound senior.

The problem authorization solves is that not every authenticated user is equal. A logged-in customer, a support agent, and a billing admin all pass the same login, yet they must see wildly different data and buttons. Without a formal authorization layer, every endpoint would hand-roll its own if user.isAdmin checks, permissions would drift, and one forgotten check becomes a breach. Authorization centralizes the rule "subject S may perform action A on resource R" so it is consistent, auditable, and changeable without redeploying business logic.

How it works, precisely

Every authorization decision reduces to evaluating a predicate over three things: a subject (the principal — user, service account, API key), an action (read, write, delete, transfer), and a resource (the specific object, e.g. invoice #4471). A Policy Decision Point (PDP) evaluates the rules and returns PERMIT or DENY; a Policy Enforcement Point (PEP) — code sitting in front of the protected operation — asks the PDP and either lets the call through or returns 403 Forbidden.

Rules come in named models. ACL (Access Control List) attaches a direct list of allowed principals to each resource: "document #4471: alice=read, bob=read+write". It is the simplest mental model and fits single-owner or small-collaborator resources, but becomes unwieldy when many resources share the same membership (every doc in a folder needs its own list). RBAC (Role-Based Access Control) assigns users to roles and roles to permissions: alice → billing_admin → {invoice:read, invoice:delete}. ABAC (Attribute-Based) evaluates conditions over attributes of subject, resource, and environment: "permit if user.dept == resource.dept and time is business hours". ReBAC (Relationship-Based, popularized by Google Zanzibar) answers "is there a path user → owner → document in the relationship graph?" PBAC (Policy-Based Access Control) elevates rules into standalone, versioned policies evaluated by a policy engine (e.g., OPA, AWS IAM policies): "allow read if principal.role == 'viewer' and resource.sensitivity != 'restricted'". It is the most expressive and audit-friendly, but adds a policy language, engine, and deployment pipeline you must operate. Crucially, authorization runs on every request, not just at login — a 403 means authenticated but not permitted, distinct from 401 which means not authenticated at all.

A worked scenario

Imagine a document SaaS like Google Drive at 50,000 QPS of API calls. Every one of those calls must be authorized — an unshared doc must never leak. Two designs:

(A) Call the PDP over the network per request. If each check adds a 2 ms RPC to a central authz service, and that service must sustain 50k QPS, it becomes a hot dependency: any blip there takes down the whole product, and you have added 2 ms to the p50 of every endpoint.

(B) Cache decisions / relationships locally. Google's Zanzibar paper (Pang et al., USENIX ATC 2019) reports serving roughly 10 million authorization QPS at <10 ms p95 globally — with >99.999% availability over three years of production use — using replicated relationship tuples and aggressive caching, with a consistency token ("zookie") to avoid the classic bug of revoking access but a stale cache still permits it. The lesson: at scale, authorization is a read-heavy, latency-critical, correctness-critical subsystem in its own right — often bigger than the feature it guards. A permission check for one doc might expand to "is user in group G, is G shared on folder F, is doc in F?" — a graph traversal you cannot afford to recompute uncached 10M times a second.

Trade-offs: which model, and when

ACL — use when a resource has a tiny, explicit guest list and no inheritance (a personal doc shared with two colleagues). It is the easiest to implement: a table of (resource_id, principal, action). Avoid when permissions must be changed in bulk across many resources or inherited from groups/folders — updating every row is error-prone.

RBAC — use when permissions cluster into a small, stable set of job functions (admin, editor, viewer). It is easy to reason about and audit. Avoid when you hit role explosion: needing billing_admin_region_EU_readonly style combinations means roles are encoding attributes they shouldn't — a smell that you've outgrown RBAC.

ABAC — use when decisions depend on context (department, clearance, time, IP, resource sensitivity). It expresses fine-grained rules without a role per combination. Avoid when policies grow so numerous that no one can predict the outcome of a given request — ABAC trades role-explosion for policy-explosion and is harder to audit ("who can access X?" becomes a search problem).

ReBAC / Zanzibar — use when permissions follow object relationships and inheritance: sharing, folder hierarchies, org charts, "friends of friends." It shines for social and document systems. Avoid when your rules aren't fundamentally relational — you'd pay for a graph engine you don't need.

PBAC — use when you need versioned, centrally authored rules that span services and must be reasoned about as first-class artifacts (OPA, AWS IAM). It gives a single policy language and audit log. Avoid when the team is not ready to operate a policy engine, debug rule evaluation, and version policy changes independently of service deploys.

The orthogonal axis is centralized vs. embedded enforcement. A central PDP (own service, or a sidecar like OPA) gives one source of truth and uniform audit, at the cost of a network hop and a shared failure domain. Embedding checks in each service is fast but risks drift and duplicated, inconsistent logic. Most mature systems land on a central policy definition with a locally-cached/embedded decision engine — policy authored once, evaluated near the request.

Pitfalls an interviewer probes

• Confusing authN with authZ. Say it cleanly: 401 = not authenticated, 403 = authenticated but not permitted. Muddling these is the classic tell.
• Broken Object-Level Authorization (BOLA/IDOR). The #1 API vulnerability (OWASP API Top 10). Checking "is this user an admin?" but not "does this user own this specific invoice #4471?" lets anyone read others' data by changing an ID in the URL. Always authorize the object instance, not just the action type.
• Trusting the client. Hiding a button in the UI is not authorization; the API must independently enforce it. Never rely on client-supplied roles/claims without server-side validation of the token.
• Stale permissions on revocation. Cached decisions or long-lived JWTs mean a fired employee keeps access until the token expires. Interviewers want to hear about short TTLs, token revocation lists, or consistency tokens (Zanzibar's zookie).
• Fail-open vs fail-closed. If the PDP is unreachable, do you PERMIT or DENY? Security-critical systems must fail closed.
• Confused deputy / privilege escalation. A service acting on a user's behalf must carry the user's authority, not its own elevated one, or callers borrow the service's power.

Key takeaways

• Authorization = what you may do, evaluated on every request as a predicate over (subject, action, resource); distinct from authentication (who you are), and signaled by 403 vs 401.
• Pick the model by shape of your rules: ACL for tiny per-resource lists, RBAC for stable job functions, ABAC for context-dependent conditions, ReBAC/Zanzibar for relationship- and sharing-driven access, PBAC for cross-service versioned policies — and watch for role-explosion or policy-explosion as the signal you've outgrown one.
• At scale it's its own subsystem: read-heavy, latency-critical, correctness-critical — cache decisions but manage staleness with short TTLs or consistency tokens so revocation actually takes effect.
• Enforce on the object instance, server-side, fail-closed: BOLA/IDOR, trusting the client, and fail-open defaults are the mistakes interviewers reliably hunt for.

Worked config: OPA as PDP behind an nginx PEP

Here is the page's PDP/PEP vocabulary as running config. OPA is the PDP: it evaluates a Rego policy over an input document and returns a decision. The gateway route is the PEP: it must turn that decision into "the request proceeds" or "the request dies with 401/403." The policy allows admins everywhere, and anyone on GET /public:

# policy.rego  (the PDP's rules)
package app.authz
import future.keywords.if
import future.keywords.in

allow if {
    input.user.role == "admin"
}

allow if {
    input.request.method == "GET"
    input.request.path == "/public"
}

The tempting wiring is broken — and silently fail-open. Pointing nginx's auth_request straight at OPA's Data API (proxy_pass http://opa:8181/v1/data/app/authz/allow;) allows every request, for two reasons. First, auth_request decides purely on the subrequest's HTTP status: any 2xx allows, only 401/403 deny. Second, OPA's Data API returns HTTP 200 for both outcomes — {"result": true} on allow, {"result": false} (or {} when undefined) on deny — so a deny can never reach nginx as a deniable status. Compounding it, the bare GET subrequest carries no input document at all, so input.user.role is always undefined. This is exactly the fail-open PEP from the pitfalls above, produced by an innocent-looking config.

The working shape puts a thin translator between the two that builds the input document and maps result to a status code — only an explicit true allows, so the PEP fails closed:

# nginx.conf
js_import authz from conf.d/authz.js;

location /api/orders {
    auth_request /_opa;
    proxy_pass http://orders;
}
location = /_opa {
    internal;
    js_content authz.check;
}

// conf.d/authz.js  (the PEP→PDP translator)
async function check(r) {
    // $request_method / $request_uri resolve from the MAIN request,
    // so the subrequest can describe the real call to OPA.
    let res = await ngx.fetch('http://opa:8181/v1/data/app/authz/allow', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ input: {
            // role must come from a VERIFIED JWT the gateway checked at authN —
            // never from a header the client can set itself
            user:    { role: r.headersIn['X-User-Role'] },
            request: { method: r.variables.request_method,
                       path:   r.variables.request_uri }
        }})
    });
    let body = await res.json().catch(() => ({}));
    r.return(body.result === true ? 204 : 403);   // anything but explicit true = deny
}
export default { check };

(Envoy users get this translation for free: the ext_authz filter with the OPA plugin natively maps deny decisions to deny statuses.) The one-sentence lesson worth repeating in an interview: a PEP that infers "allow" from "the PDP answered successfully" is fail-open by construction — the transport status and the decision are different channels, and the PEP must read the decision.