Relationship-Based Access Control (ReBAC)
What is relationship-based access control?
Relationship-based access control (ReBAC) is an authorization model that decides access by looking at how entities are connected. Users, groups, documents, folders and projects are nodes in a graph, and relationships such as "owner of", "member of" or "parent of" are the edges between them. A user gets access when a qualifying path exists from them to the resource.
ReBAC isn't a replacement for role-based access control (RBAC) or attribute-based access control (ABAC) so much as a generalization of them. Role membership is one kind of relationship, and ABAC can encode relationships as attributes; it just gets complicated at scale. A rule like "friends of friends can see this post" is awkward to write as a role or an attribute, but simple as a relationship.
How ReBAC works
ReBAC policies describe relationships between entities as paths in a graph. When an identity requests access, the system checks whether a path exists from that identity to the resource that satisfies the policy, and grants or denies access at the moment of the action.
For example, a policy might allow a user to open a document if they are its author, a reviewer assigned to it or a member of the team that owns the project it belongs to. In the graph, the author and reviewer are direct edges from the user to the document. Team membership is a longer path: user to team, team to project, project to document. If any of those paths exists, access is granted. If the user leaves the team, the path and the access it granted disappear.
Benefits of ReBAC
ReBAC states policies in terms of how entities relate, which RBAC and ABAC can only approximate with a role or attribute per relationship. Four things follow from that:
- Permissions follow structure. Share a folder and its contents follow. Move a project to a new team and access moves with it.
- Fewer roles to manage. Instead of creating a role for every project or account, one set of relationships describes the structure and access follows from it.
- Fine-grained by default. Access can be granted to a single object, not just a category of objects.
- Auditable decisions. The path that granted access is the record of why, which simplifies audits and troubleshooting.
Access changes when relationships change. When a user leaves a team or a document gains a new reviewer, nobody edits roles or permissions, and people leave less standing privilege behind when they move between teams or projects.
Where is ReBAC used?
ReBAC fits applications where permissions follow structure:
- Document and file sharing. Folders, shared drives and "anyone in this workspace" links are relationship graphs. Google Drive, built on Zanzibar, is the best-known example.
- Multi-tenant SaaS. Users belong to organizations, organizations own projects and access is inherited through that hierarchy.
- Developer platforms. Repositories belong to orgs and teams, and permissions follow team membership.
- Healthcare. A clinician sees a patient's record because they're on that patient's care team, not because of a broad rule.
Challenges of ReBAC
The main challenge of ReBAC is scale. As the number of entities and relationships grows, the graph becomes harder to keep in sync with the systems it describes, and evaluating long relationship paths can slow access decisions.
There is also no widely adopted standard language for ReBAC policies. Google's Zanzibar paper is the common reference model, and open-source engines such as OpenFGA and SpiceDB implement it. Most organizations adopt one of those rather than building their own.
ReBAC has limits. When a decision depends on context such as time, location, device posture or risk, ABAC or a policy engine is the better fit. For these reasons, ReBAC is usually combined with RBAC or ABAC rather than used on its own: roles or attributes handle the broad rules, and relationships handle the cases they can't express.
More resources
Blog
The access control paradigm: Unpacking ABAC, PBAC and RBAC