08 — Authorization: Access-Control Models (RBAC, ABAC, PBAC, ReBAC)

Authorization sat in my head as a pile of acronyms until I found the single question they all answer. The model that finally clicked: every authorization model is a different way to evaluate a yes/no question — "may subject S do action A on resource R, in context C" — and the models trade off simplicity against how fine-grained and context-aware that decision can be. [1] RBAC, ABAC, PBAC, DAC, MAC, and ReBAC are not competing products; they're points on that tradeoff curve, and the right one depends on how rich the decision needs to be.

The question every model evaluates has the same four inputs: a subject (who), an action (what verb), a resource (what thing), and an environment (what context). The differences are which of those inputs each model considers and how the rules are expressed. That single framing made the alphabet soup readable.

RBAC: by role

Role-Based Access Control (RBAC) is the workhorse — and almost certainly the one to start with. Permissions are assigned to roles (admin, editor, viewer), users are assigned roles, and the decision is "does this user's role include the permission for this action?" [2] A viewer can GET but not PUT; an editor can do both but not delete; an admin can do everything.

RBAC's appeal is simplicity. The decision is a fast lookup against a small set of roles, the model is easy to audit ("who can delete? the admin role"), and it maps cleanly onto organizational structure. The limitation is granularity: if two editors need different permissions, RBAC has to invent a new role for each variant, and role proliferation eventually makes the model unreadable. RBAC is the right default for the majority of APIs; you reach for the more expressive models when RBAC's coarseness starts hurting.

ABAC: by attributes

Attribute-Based Access Control (ABAC) considers attributes of the subject, resource, action, and environment, and evaluates a rule against them [3]. "Allow if subject.department = resource.department AND action = read AND environment.time = business-hours." The decision can be as fine-grained as the attributes you track.

The tradeoff is power versus complexity. ABAC can express policies RBAC can't ("a doctor may read a record only if the patient is assigned to them and it's during their shift"), but authoring and debugging attribute rules is harder than managing roles. ABAC is the choice when access decisions are genuinely context-dependent — healthcare, finance, multi-tenant systems where "who you are" isn't enough and "what you're touching, when, from where" matters.

PBAC: by policy

Policy-Based Access Control (PBAC) generalizes the idea: access is decided by evaluating a set of written policies, each of which can consider any combination of roles, attributes, relationships, and context [4]. PBAC is less a distinct mechanism and more the umbrella under which ABAC-style rules live, often managed in a dedicated policy engine (OPA, Cedar) so policies are decoupled from application code.

The way of thinking: PBAC externalizes the decision logic into a policy layer the team can version, review, and audit independently of the API. This pays off in larger systems where rules evolve often or must satisfy compliance review. The cost is a new component to operate and a policy language to learn. PBAC earns its complexity in organizations where authorization rules are themselves a first-class artifact.

DAC and MAC: the classical pair

Two older models from operating-system security still show up in API contexts:

• Discretionary Access Control (DAC) — the owner of a resource decides who may access it [5]. A user creates a document and grants read to specific colleagues. Flexible, but trust flows from the owner's judgment, which can leak access if an owner is careless. Most file-sharing systems are DAC.
• Mandatory Access Control (MAC) — a central authority assigns security labels to resources and clearance levels to users, and access is granted only if the user's clearance dominates the resource's label [6]. No user can override it. Rigid, centralized, and used where the rules are non-negotiable — government, military, classified systems.

The pair sits at opposite ends of "who decides." DAC trusts the owner; MAC trusts a central authority and no one else. Neither is common in a typical CRUD API, but they're the right vocabulary when the domain demands them — DAC for collaborative document systems, MAC for regulated classified environments.

ReBAC: by relationship

Relationship-Based Access Control (ReBAC) decides access based on the relationships between entities — the model Google uses for "can X see Y because X is in the group that owns Y's parent folder." [7] Instead of (or in addition to) roles and attributes, ReBAC walks a graph: subject → relationship → resource.

user:alice —editor→ folder:projects
folder:projects —parent→ document:spec
∴ alice may edit document:spec (inherited via the folder)

ReBAC's strength is inheritance through hierarchy — permissions flow down a relationship graph, so adding a user to a team grants them everything under it without per-resource rules. This is the right model for systems with rich, nested ownership: file systems, organization/team structures, social-graph permissions ("friends of friends"). The cost is a graph engine to evaluate the relationships (Google Zanzibar, SpiceDB, OpenFGA) and the conceptual overhead of modeling your domain as a graph. ReBAC pays off precisely when access decisions are naturally relational — "who can access what" is really "who is connected to what."

How I use this

I start with RBAC and let the domain push me toward more expressive models. Most APIs never need more than roles. If I find myself inventing a role per tenant, per time-of-day, or per resource-owner, that's the signal to move — to ABAC when context drives the decision, to PBAC when policies need to be externalized and audited, to ReBAC when access is naturally a graph of relationships, to DAC when resource owners should decide, to MAC when a central label authority is non-negotiable. The wrong move is picking the most powerful model by default — ReBAC or ABAC on a simple app adds enormous complexity for permissions RBAC would have handled in three roles. Match the model to the actual richness of the decision.

References

[1] Ping Identity, "API Authorization Methods," 2024. [Online]. Available: https://www.pingidentity.com/en/resources/identity-fundamentals/authorization/authorization-methods.html

[2] Red Hat, "What is Role-based Access Control (RBAC)?," 2024. [Online]. Available: https://www.redhat.com/en/topics/security/what-is-role-based-access-control

[3] Okta, "What is Attribute Based Access Control?," 2024. [Online]. Available: https://www.okta.com/uk/blog/2020/09/attribute-based-access-control-abac/

[4] Ping Identity, "Policy Based Access Control (PBAC) Explained," 2024. [Online]. Available: https://www.pingidentity.com/en/resources/blog/post/policy-based-access-control.html

[5] Built In, "Guide to Discretionary Access Control (DAC) With Examples," 2024. [Online]. Available: https://builtin.com/articles/discretionary-access-control

[6] TechTarget, "mandatory access control (MAC)," 2024. [Online]. Available: https://www.techtarget.com/searchsecurity/definition/mandatory-access-control-MAC

[7] freeCodeCamp, "How to Implement Relationship Based Access Control (ReBAC)," 2024. [Online]. Available: https://www.freecodecamp.org/news/implement-relationship-based-access-control/