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.
Frequently asked questions
- What is RBAC?
- RBAC stands for Role-Based Access Control: permissions are assigned to roles, and users gain permissions through the roles they hold.
- What is ABAC?
- ABAC stands for Attribute-Based Access Control: access decisions are made from attributes of the user, resource, action, and context, such as department, location, or time.
- What is ReBAC?
- ReBAC stands for Relationship-Based Access Control: permissions derive from relationships between entities, such as a user being a member or owner of a resource, an approach popularized by Google Zanzibar.
- Which access control model should I use?
- RBAC is simplest for coarse roles, ABAC fits context-rich policies, and ReBAC suits fine-grained, relationship-heavy permissions. Many systems combine them.