Glossary
Relationship-based access control (ReBAC) is an authorization model that grants access based on the relationships between users and resources: for example, "a user can edit a document if they are its owner, or a member of a team the document is shared with." It excels at fine-grained, hierarchical, and shared-resource permissions that role- or attribute-based models handle awkwardly.
ReBAC gained prominence through large-scale systems (notably Google’s Zanzibar, which powers permissions across Google’s products) and is now the model behind many modern fine-grained authorization services.
ReBAC represents permissions as a graph of relationships between entities: users, groups, resources, and the connections among them. Access is decided by traversing these relationships, is there a path from this user to this resource that grants the requested permission? For example, "user is a member of a group that has editor access to a folder that contains this document" resolves to edit access via the relationship chain. This graph model naturally handles nesting, inheritance, and sharing.
ReBAC shines exactly where RBAC and ABAC struggle: fine-grained, per-resource permissions and complex sharing hierarchies. Think of a document platform where each file can be shared with specific users, groups, or teams, with inherited folder permissions, expressing that with roles would require an unmanageable explosion of them, but it maps cleanly to relationships. ReBAC is the model of choice for applications with rich sharing and collaboration semantics, and it scales to billions of objects, as Zanzibar demonstrated.
ReBAC is closely tied to the rise of fine-grained authorization (FGA) as a discipline and product category. Modern FGA services often use a ReBAC (Zanzibar-inspired) model to answer per-resource authorization questions at scale and low latency. For developers, this means offloading complex permission logic to a purpose-built service rather than encoding tangled relationship checks throughout application code.
ReBAC is worth adopting when access depends on relationships (ownership, membership, sharing, hierarchy) especially at fine granularity and large scale. For simpler needs, RBAC may suffice, and for attribute-driven conditions, ABAC fits. Many real systems blend models, but where rich, per-object sharing is central, ReBAC is usually the right foundation.
What is ReBAC?
An authorization model that grants access based on relationships between users and resources, ideal for fine-grained and shared-resource permissions.
How does ReBAC work?
It models permissions as a graph of relationships and decides access by traversing them (e.g., user → group → folder → document).
What is ReBAC good for?
Fine-grained, per-resource permissions and complex sharing hierarchies that would cause role explosion under RBAC.
What is Zanzibar?
Google’s large-scale authorization system that popularized the ReBAC model and inspired many modern fine-grained authorization services.
Related: Fine-Grained Authorization (FGA) · Role-Based Access Control (RBAC) · Attribute-Based Access Control (ABAC) · Authorization
