Authorization

Authorization answers: "given this authenticated identity, what can they do?" It runs after authentication on every request.

Two models dominate:

• RBAC (Role-Based Access Control): users have roles (admin, editor, viewer); roles have permissions (delete_post, edit_post, view_post). Authorization = check the user's role has the required permission. Simple, common, sufficient for most apps.

• ABAC (Attribute-Based Access Control): rules combine attributes of the user, the resource, the action, and the environment. "A user in the finance department can view invoices under $10k from their region during business hours." More expressive, more complex.

RBAC is the right starting point; ABAC when RBAC isn't expressive enough. Most systems use RBAC for coarse permissions and add per-resource checks for fine-grained control.

The most common authorization bug is missing per-resource checks. Consider:

• A user has edit_post permission.
• They send POST /posts/999/edit.
• Does the user own post 999? If you didn't check, they just edited someone else's post.

This is an IDOR (Insecure Direct Object Reference) vulnerability, and it's everywhere. The fix is mandatory per-resource authorization: every request that touches a specific resource checks not just "can the user do this action" but "can the user do this action to THIS resource."

Implementation: in the controller, fetch the resource first, then check user.id == resource.owner_id (or a more complex policy) before performing the action. If the check fails, return 404 (not 403, to avoid leaking the resource's existence).

The pattern of "hide the edit button if not owner" is necessary for UX but never sufficient for security — the user can craft the request manually. Server-side enforcement is the only check that matters.

Authorization logic spread across controllers rots. The pattern that scales:

• Centralize policy: a single authorization layer (a policy engine or middleware) that all requests pass through. It consults the user's roles, the resource's owner, and the action being performed.
• Declarative policy: define policies as data, not code. Tools like OPA (Open Policy Agent), AWS IAM, and Casbin express policies in a DSL that's auditable and version-controlled.
• Deny by default: if no policy explicitly permits an action, deny it. This prevents "I forgot to check" bugs from becoming security holes.
• Audit log: every authorization decision is logged. "alice viewed post 42 at 10:42:03." Essential for incident response and compliance.

For microservices, a service mesh or API gateway can enforce coarse authorization ("is the user authenticated? does their token have the required scope?") centrally, with fine-grained per-resource checks in the service. This splits the work: the gateway handles cross-cutting concerns; the service handles business logic.

In API and OAuth contexts, authorization often uses scopes — strings that grant specific permissions. A token might have scopes read:posts write:posts but not delete:posts. The API checks the token's scopes before performing each action.

Scopes are a middle ground between RBAC and ABAC:

• Like RBAC: a fixed set of named permissions.
• Like ABAC: scoped to a specific resource or action.

The principle of least privilege: grant only the scopes needed for the task. An app that reads your GitHub repos should request read:user public_repo, not repo (which would grant write to all repos). Most OAuth flows let the user see and approve the requested scopes.

Scopes must be enforced server-side, just like RBAC — checking the scope on read but not write is a common bug.

Mental model. Think of Authorization as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Authorization mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose Authorization, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

A practical blast-radius question: if one credential is compromised, how many users, services, records or regions could it affect? Prefer designs where that number is deliberately bounded.