RBAC vs ABAC vs ReBAC: Which Access Control Model to Use

RBAC vs ABAC vs ReBAC: RBAC grants access through roles, ABAC evaluates attributes of the user, resource and context, and ReBAC derives access from relationships between objects. Use RBAC when permissions fit a short list of job functions, ABAC when access depends on data already on the request, and ReBAC when access follows ownership, membership or hierarchy. Most production systems blend them: roles for the coarse grant, attributes or relationships for the fine-grained condition.

Once a user is authenticated, authorization decides what they can do, and this is where the most severe application vulnerabilities live. Broken Access Control is A01 in the OWASP Top 10:2025, as it was in the 2021 edition, so choose the model deliberately rather than letting one accrete.

RBAC vs ABAC vs ReBAC compared

RBAC (role-based)

Access is granted through roles (admin, editor, viewer). NIST formalized the model in 1992 and it became ANSI INCITS 359 in 2004. Simple, well understood, and easy to audit, but it tends toward role explosion as every exception becomes a new role, and toward role accumulation when people change jobs.

How to implement RBAC, in brief: list the permissions your application exposes; group them into a small set of roles mapped to job functions; assign roles to groups from your identity provider, not to individuals; check permission on the server for every object; and review membership on a schedule. The implementing RBAC guide and role mining cover the detail.

ABAC (attribute-based)

Decisions use attributes of the user, resource, action, and context (department, region, time, sensitivity). NIST SP 800-162 describes ABAC as evaluating attributes of the subject, object and requested operation, and sometimes the environment, against policy. An ABAC policy in Cedar, the language behind Amazon Verified Permissions:

permit(principal, action == Action::"view", resource)
when { resource.tenant == principal.tenant && resource.status != "locked" };

Far more expressive than roles, but policies get hard to reason about. See implementing ABAC.

ReBAC (relationship-based)

Access flows from relationships between objects, the model behind Google Zanzibar. The Zanzibar paper reports trillions of access control lists, millions of authorization requests per second, 95th-percentile latency under 10 milliseconds and availability above 99.999% over three years. Relationships are stored as tuples:

folder:roadmap#editor@team:platform#member
document:q3-plan#parent@folder:roadmap

A check for "can Anne view q3-plan" walks from the document to its folder to the team Anne belongs to. ReBAC is ideal for sharing, hierarchies, and nested ownership, and it needs a relationship store and careful modeling. See RBAC to ReBAC.

What real systems actually do

The models are presented as alternatives and used as layers:

role: billing_admin          # coarse: can this class of user touch billing at all
condition: resource.tenant == principal.tenant AND resource.status != 'locked'

Trying to express the condition as roles produces role explosion. Trying to express the coarse grant as attributes produces policies nobody can audit.

The questions that decide the model

• Does access depend on a relationship that changes constantly? Ownership, sharing, membership, folder inheritance. If yes, ReBAC.
• Does access depend on data already on the request? Tenant, department, resource status, time. If yes, ABAC with a stateless engine, because there is no second data store to keep consistent.
• Can you list the permissions on one page? Then RBAC is enough and adding an engine is overhead.

How access control fails in practice

• No object-level check at all. The Optus breach in 2022 came from an internet-facing API that returned customer data without valid authorization, affecting about 9.5 million people. No model helps if the check is missing.
• Roles that only grow. Mover entitlement accumulation is RBAC's typical failure: provisioning adds the new role and nothing removes the old one.
• Bugs in the policy layer itself. CVE-2026-5712, a role-editing authorization flaw in SailPoint IdentityIQ, and CVE-2025-14778, a Keycloak UMA policy privilege escalation, show that the engine is part of your attack surface.
• Delegation that widens access. In agent and microservice chains, one hop that trusts the scope a caller claims produces scope escalation through delegation.

The operational costs people underestimate

ReBAC means running a stateful service on the request path and reasoning about consistency: a check that reads stale relationship data grants stale access, and the window after a revocation is a real security property. ABAC means every attribute a decision depends on must be present in the request, which is easy for request-scoped data and hard for anything requiring a lookup. Both mean authorization is now a service that must be available, fast, and versioned, because a policy change is a production change.

Authorization engines in 2026

Whichever engine you choose, call it through the AuthZEN Authorization API 1.0, a Final OpenID Foundation specification since January 11, 2026, so the application code does not depend on one vendor's SDK. Compare engines in the best authorization tools ranking, OpenFGA vs Cerbos, AuthZed vs OpenFGA and the open source authorization tools roundup, and see fine-grained authorization.