Relationship-Based Access Control (ReBAC)
Relationship-Based Access Control, or ReBAC, is an authorization model that makes decisions based on the relationships between subjects, resources, and other entities.
- Acronym
- ReBAC
- Synonym
- Relationship-Based Access Control
Definition
Relationship-Based Access Control, or ReBAC, is an authorization approach in which access is determined by graph-like relationships such as owner of, manager of, member of, approver for, delegated by, editor of, or parent of. Instead of relying mainly on roles or attributes, ReBAC focuses on how entities are connected. This model is especially useful in collaboration systems, content platforms, healthcare, B2B sharing, delegated administration, and multi-tenant environments where access depends on resource ownership, hierarchy, or business relationships. ReBAC often provides a more natural expression of object-level permissions and delegated access patterns than traditional RBAC.
How does ReBAC work?
ReBAC represents authorization-relevant facts as relationships between subjects and resources. A permission can be direct — “Alice owns this document” — or derived through a chain of relationships.
If the authorization model allows members of the team that owns a folder to access its documents, Alice can inherit that permission without creating an individual entitlement for every document.
Systems inspired by Google Zanzibar commonly represent these relationships as relationship tuples and evaluate whether a chain of relationships satisfies the requested permission.
- Alice
- member of
- Finance Team
- owner of
- Budget Folder
Why it matters
ReBAC is highly relevant for modern applications where authorization depends on who is related to what, not only on organizational role. It feels particularly natural when sharing, ownership, delegation or resource hierarchies are directly part of how the application works.
The Ariovis perspective
ReBAC is an excellent model when relationships naturally represent the business reality behind authorization.
Ariovis avoids turning an authorization engine into a new repository for the entire reality of the information system when this is unnecessary. A decision may also depend on identity, attributes, context, risk, resource classification or information held by business applications.
In these situations, we generally favor a policy-driven approach able to combine the right information when the decision is made. ReBAC and PBAC are not necessarily competing approaches: a relationship can itself become one of the inputs evaluated by a policy.
Related services
Common pitfalls
- Teams sometimes underestimate the governance of relationships: who creates them, who updates them and which system is authoritative? Inheritance and indirect relationship chains can also make authorization decisions harder to analyze. A ReBAC model therefore needs to remain explainable, maintainable and properly synchronized with the systems that hold the underlying business reality.
Related architectures and technologies
- Google ZanzibarReference architecture
Authorization system published by Google, designed to handle relationships and permissions consistently at very large scale. Zanzibar strongly influenced modern ReBAC architectures.
- OpenFGAReBAC authorization engine
Open source project inspired by the Zanzibar principles, based on authorization models and relationships between users and objects.
- SpiceDBZanzibar-inspired authorization system
Open source relationship-based permission system developed by AuthZed and directly inspired by the Google Zanzibar architecture.
Further reading
- ReBAC vs PBAC: should you model relationships or query the right data?Our architectural view: when the relationship is the right data, and when the policy should orchestrate several sources of truth.
- Fine-grained authorizationHow Ariovis designs, integrates and operates context-aware authorization decisions.
- PBAC: the next generation of access controlPDP, PEP, PAP and PIP: the natural extension towards a policy-driven approach.
Explore this category
These concepts matter most inside a real project.
The first conversation helps establish your context, the systems involved and the next useful decision.