RBAC vs ABAC vs ReBAC: Choosing an Authorization Model

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 present on the request, and ReBAC when access follows from 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 has held the top position in the OWASP Top 10 since the 2021 revision, which is a good reason to choose the model deliberately rather than letting one accrete.

RBAC (role-based)

Access is granted through roles (admin, editor, viewer). Simple, well understood, and easy to audit, but it tends toward role explosion as you add exceptions and fine-grained needs.

ABAC (attribute-based)

Decisions use attributes of the user, resource, action, and context (department, region, time, sensitivity). Far more expressive than roles, but policies can get complex and hard to reason about.

ReBAC (relationship-based)

Access flows from relationships between objects, the model behind Google Zanzibar. Ideal for sharing, hierarchies, and nested ownership ("can this user view this document because they belong to its parent folder's team"). It needs a relationship store and careful modeling.

How to choose

• Simple apps with clear roles: RBAC.
• Rules driven by attributes and context: ABAC.
• Sharing, hierarchies, multi-tenant graphs: ReBAC.

Many teams externalize this to a dedicated engine. Browse authorization vendors and compare OpenFGA vs Cerbos.

What real systems actually do

The models are presented as alternatives and used as layers. The pattern that holds up is roles for the coarse grant, attributes or relationships for the fine-grained condition:

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, because expressing "can view because they belong to the parent folder's team" in roles or attributes is painful.
• 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.

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, not an implementation detail.

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. See OpenFGA vs Cerbos for how the two shapes differ in practice, and fine-grained authorization.

Where to start

Where to start

Read implementing RBAC and RBAC to ReBAC.