RBAC vs ABAC vs ReBAC: Choosing an Authorization Model

Once a user is authenticated, authorization decides what they can do. The three dominant models are RBAC, ABAC, and ReBAC, and most real systems blend them.

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.

Where to start

Read implementing RBAC and RBAC to ReBAC.