Identity & Access Control
Relationship-based access control
Relationship-based access control (ReBAC) grants or denies access based on the relationships between subjects, resources, and other entities in the system, rather than on roles or static attributes alone.
In plain terms
Relationship-based access control (ReBAC) grants access based on relationships - “you can edit this document because you own it,” “you can see this folder because you are on the team.” Access follows connections rather than fixed roles.
By evaluating dynamic connections between users, groups, and data objects at request time, relationship-based access control (ReBAC) determines permissions through a graph of interactions rather than relying on static roles or user attributes. A user may read a document because they are its owner, because they are a member of a workspace that contains it, or because someone with a sharing right granted them access. ReBAC describes these chains explicitly and evaluates them at request time.
ReBAC differs from role-based access control. RBAC assigns permissions to roles, then assigns users to roles, which works well when access patterns map cleanly to job functions. ReBAC instead models access as a graph of typed connections between entities, which fits collaboration platforms, social products, and multi-tenant SaaS where ownership, sharing, and group membership cannot be reduced to a fixed role list.
ReBAC also differs from attribute-based access control. ABAC evaluates rules over subject, resource, action, and environment attributes. ReBAC focuses on whether a path of relationships exists between subject and resource. The two approaches can be combined, but the core question in ReBAC is structural: does a permitted relationship chain connect this user to this resource right now.
A common reference for ReBAC is Google’s Zanzibar paper, which describes a globally consistent authorization system based on tuple data and relation definitions. Open-source projects such as OpenFGA, SpiceDB, and Permify implement similar ideas. Each defines object types, allowed relations, and rewrite rules that compute permissions from base relations.
The data model is a key part of any ReBAC system. Tuples typically record that a subject has a specific relation to an object, for example that a user is an editor of a document, that a group is a member of a workspace, or that a folder is the parent of a document. Permissions such as can_read or can_write are then derived from these relations using union, intersection, exclusion, and traversal rules.
ReBAC enables fine-grained sharing without exploding role definitions. A document can be shared with one specific user, an entire team, an external collaborator, or a parent folder’s inherited audience, all without inventing new roles. The relationship graph captures intent directly, which simplifies the authorization model for collaboration features.
Performance and consistency are nontrivial. Authorization checks must be fast and correct as the relationship graph changes. ReBAC systems often use specialized stores, caching, and consistency tokens to ensure that, for example, a permission that was just revoked is not honored by a stale cache. Designers must understand the consistency guarantees their chosen system offers.
ReBAC supports useful security properties. Least-privilege access can be enforced by avoiding broad role grants in favor of explicit relations. Sharing can be reviewed because relations are queryable data, not implicit role inheritance. Audit trails can record which relation enabled which access decision, which helps incident response and access reviews.
ReBAC has limits. Some controls map poorly to relationships, such as time-of-day restrictions, environmental signals, or risk-based decisions, which fit ABAC or risk engines better. Most production systems combine ReBAC with attribute checks and policy evaluation, especially for regulated data, privileged operations, and conditional access requirements.
Governance must follow the data model. Relations should have clear semantics, lifecycle rules, and ownership. Stale relations create silent over-permission, especially when users leave teams, projects close, or external collaborations end. Access certification and identity lifecycle management must include relationship cleanup.
Externalized authorization works naturally with ReBAC. A policy decision point can consume the relationship graph and return a permit or deny result for each request, while applications stay focused on business logic. This separation supports consistent enforcement across multiple services that share the same authorization model.
ReBAC is most powerful when relationships reflect real domain meaning. Defining them by copying the database schema or by reflecting database joins tends to produce confusing models. Designers should start from the access language users already understand, such as ownership, membership, sharing, and inheritance, and model those directly.
Adopting ReBAC is a significant architectural choice. Teams should evaluate whether the application’s access patterns benefit from a graph model, whether the chosen system meets consistency and performance requirements, and whether the operations and security teams are prepared to govern relationship data the same way they govern roles, groups, and permissions today.