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.
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.
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:
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.
ReBAC fits applications where permissions follow structure:
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.
Blog
The access control paradigm: Unpacking ABAC, PBAC and RBAC