What Is ReBAC? Relationship-Based Access Control Explained with Examples and Use Cases

A Story: The Shared Document

Imagine you are working on a project with three colleagues. You create a document and share it with them — they can edit it. They, in turn, share it with a few other people who can only view it. One of those viewers shares it with their manager, who gets comment access.

Now try to answer a simple question: who has access to this document?

The answer is not a flat list. It depends entirely on relationships. You own the document. You shared it directly with three people. They shared it onward. Some of those shares carried edit rights. Some carried view rights. Some carried comment rights. The permissions are not stored on the document as a static list — they are derived from the web of connections between people and the resource.

Now scale that up. Thousands of documents, thousands of users, millions of sharing relationships. Someone asks: what documents can Alice access? Again, the answer flows through relationships. Alice can access documents she owns, documents shared with her directly, documents shared with a group she belongs to, and documents that were shared transitively — someone shared with someone who shared with her.

This is ReBAC. Relationship-Based Access Control. This article explains what it is, how it differs from RBAC, ABAC, and ACLs, and why it has become the standard model for collaboration platforms, social networks, and any system where access flows through connections between people and resources.

What Is ReBAC?

Relationship-Based Access Control is an authorization model where permissions are derived from the relationships between users and resources — and sometimes between resources themselves.

Rather than asking "what role does this user have?" or "what attributes does this resource carry?", ReBAC asks: "how is this user connected to this resource?"

Access is not granted directly — it flows through relationships. If Alice shares a document with Bob, Bob now has a relationship to that document. If Bob shares it with Carol, Carol has a relationship through Bob. The permission follows the relationship chain.

A simple example makes this concrete:

1. Alice owns Document X
2. Alice shares Document X with Bob as an editor
3. Bob shares Document X with Carol as a viewer

From this, the system derives that Alice can edit and share (because she owns it), Bob can edit (because Alice established that relationship), and Carol can view (because Bob established that relationship). No role was created. No attribute was checked. Permissions came entirely from the connections between entities.

The Problem ReBAC Solves

To understand why ReBAC exists, you need to see where other models break down when relationships are at the centre of your authorization problem.

Where RBAC fails. RBAC works well when permissions are stable and group-based. In collaboration systems, permissions are dynamic and individual. Alice wants to share a document specifically with Bob — not with everyone in a group. Creating a role called "CanViewDocumentX" for every document and every user combination is unworkable. RBAC has no native mechanism for one-to-one sharing at scale.

Where ACLs fail. ACLs can handle one-to-one sharing. You attach an entry to Document X saying "Bob can view." This works for one document. But ACLs are flat — they store permissions directly on the resource with no concept of permission flowing between users. If Bob shares Document X with Carol, you must add a new ACL entry for Carol. If Carol shares with David, you add another. The list grows with every share, and there is no way to express "anyone Bob shares with gets view access" without enumerating each person individually. Revocation becomes a cleanup problem.

Where ABAC fails. ABAC can express some relationships through attributes. You could add an attribute to a user saying they have sharing rights. But ABAC cannot easily express chains of relationships. "Carol can view because Bob shared it with her, and Alice shared it with Bob" requires tracking the history of shares as attributes — something ABAC was not designed to do. It becomes unmanageable quickly.

ReBAC solves the problem of dynamic, transitive, relationship-driven access. It is built for systems where users share resources with specific individuals (not just groups), where permissions can flow from one user to another, where access changes constantly as shares are added and removed, and where the number of relationships is enormous.

Core Concepts

ReBAC introduces a set of concepts that do not appear in other authorization models.

Relationships

A relationship is a typed connection between two entities — usually a user and a resource, but sometimes between two resources or two users. Common relationship types include owner, editor, viewer, commenter, member, and parent. Each relationship has a direction: Alice owns Document X, or Document X is parent_of File Y. Direction matters when the system traverses the graph to determine access.

Subjects and Objects

In ReBAC terminology, the subject is the entity requesting access (typically a user) and the object is the resource being accessed. The authorization question becomes: does a path of relationships exist between this subject and this object that grants the requested permission?

Transitivity

Transitivity is the central innovation of ReBAC, and it is what makes the model both powerful and complex.

A relationship is transitive when permissions can flow through intermediate connections. If Alice owns Folder A, and Folder A contains File B, then Alice can access File B — even though no permission was explicitly granted on File B itself. The access flows through the folder relationship. This is inheritance: access derived from a resource's position in a hierarchy.

Transitivity also appears in user-to-user chains. Alice shares Document X with Bob as editor. Bob shares it with Carol as viewer. Carol gets view access through the chain Alice → Bob → Carol. Note that the permission type can change at each step in the chain — Bob cannot grant Carol more than he himself has, but he can grant less.

It is worth distinguishing two flavours of transitivity that often appear together. The first is permission inheritance, where a child resource inherits permissions from its parent (a file inherits from its folder). The second is delegation, where a user passes their access rights to another user. Both are forms of transitivity, but they have different implications for how you model and control permission propagation.

Graph-Based Authorization

ReBAC represents relationships as a directed graph — nodes are users, resources, and groups; edges are relationships. Authorization is a graph traversal problem. To check whether Carol can view Document X, the system asks: is there a path from Carol to Document X through edges that collectively grant view permission? If yes, access is granted. If no path exists, it is denied.

This is a fundamentally different computational model from RBAC (a lookup table) or ABAC (a policy evaluation engine). It scales naturally to complex, interconnected permission structures, but it also introduces challenges in performance and consistency that we will cover shortly.

ReBAC vs Other Models

Understanding where ReBAC fits requires seeing clearly what each model is optimised for — and where each one runs out of road.

ReBAC vs RBAC. RBAC answers "what role does the user have?" and grants access based on group membership. Its strength is simplicity and auditability in stable, hierarchical environments. Its weakness is that it cannot model individual sharing. RBAC says "Managers can approve expenses." ReBAC says "Alice can edit this document because Bob shared it with her." These are fundamentally different authorization questions, and ReBAC is the tool for the second one.

ReBAC vs ABAC. ABAC answers "do the attributes of this user, resource, and environment satisfy this policy?" It handles context-aware rules well — time of day, device type, classification level. What it handles poorly is chains of relationships between entities. ABAC says "Finance users can access Finance documents." ReBAC says "Users who have been shared a document by its owner can view it." ABAC can approximate some ReBAC scenarios through clever attribute modelling, but the result is fragile and hard to maintain at scale.

ReBAC vs ACLs. ACLs store permissions directly on the resource as a flat list. They handle per-resource exceptions well and are conceptually simple. Their weakness is that the list must enumerate every permitted user individually — there is no concept of permission flowing between users. ReBAC stores relationship edges in a graph and computes access by traversal. When Bob loses access, Carol (who accessed through Bob) automatically loses access too. In an ACL system, you must find and delete Carol's entry manually.

It is also worth noting that ReBAC is not a replacement for these models. Most production systems layer them together: RBAC for baseline organisational roles, ABAC for context-sensitive decisions, ACLs for one-off exceptions, and ReBAC for dynamic sharing and collaboration. Each addresses a different class of authorization problem.

Where ReBAC Naturally Emerges

ReBAC is not a new or exotic idea — you have used it many times without calling it that.

Document collaboration platforms. Document collaboration platforms offer a useful way to see how these models blend rather than compete. When you first share a document with a specific person, you are effectively creating an ACL entry — a direct permission attached to that resource. But the moment that person shares it onward, and permissions begin to flow through chains of users, the system is no longer operating as a simple list. It evolves into a relationship graph, where access is derived not just from who was explicitly granted permission, but from how users are connected through sharing actions. Systems like Google Drive, SharePoint, and Dropbox therefore begin with ACL-like semantics at the point of sharing, but at scale they behave like ReBAC systems — storing relationships and computing access dynamically, with constructs like “anyone with the link” acting as specialized relationship types rather than static entries.

Social networks. When you post something and set privacy to "friends of friends," you are using ReBAC. The system checks the relationship graph: is this viewer a friend of a friend of the poster? That is a two-hop transitive traversal. LinkedIn's "2nd connections" and Facebook's privacy controls are ReBAC in practice.

Organisational hierarchies. A manager should see records of their direct reports. A director should see records of their direct reports and their reports' reports. This flows naturally from a "reports_to" relationship chained through an org chart — classic transitivity.

Project management tools. When you are added to a project in Jira or Asana, you can see all tasks in that project. When a task is specifically assigned to you, you can see it even if you are not a project member. These are different relationship types — project_member and task_assignee — granting different access paths to the same underlying resources.

Google Zanzibar: The Reference Implementation

Google Zanzibar is the most influential ReBAC system ever built, and understanding it is essential context for anyone implementing ReBAC at scale.

Zanzibar is Google's global authorisation system. It powers access control for Google Drive, Google Calendar, YouTube, and many other Google services — handling trillions of access checks per day across billions of users and resources, with access decisions completing in single-digit milliseconds.

Zanzibar stores relationships as tuples — simple statements of the form "User U has relationship R to Object O." For example: Alice is an owner of document_x; Bob is an editor of document_x; document_x has folder_a as its parent. To answer "can Alice view document_x?", Zanzibar traverses the graph of tuples, following relationship chains until it finds a path that grants the permission or exhausts all possibilities.

Zanzibar also introduced a clean language for expressing relationship-based policies — defining which relationship types transitively imply others, and which combinations grant which permissions. This has become the conceptual foundation for open-source successors including SpiceDB, Ory Keto, and OpenFGA.

When to Use ReBAC

ReBAC is not the right choice for every system. It earns its complexity when your authorization needs are fundamentally driven by relationships.

Use ReBAC when: users share resources with specific individuals (not just groups); permissions flow through chains from one user to another; the set of relationships is large and changes constantly; and you need to answer the inverse question — given a user, what can they access? — efficiently.

ReBAC may be overkill when: your system has a small number of stable user types with no user-to-user sharing; only administrators grant permissions and users do not share resources with each other; or your scale is small enough that a relational database with simple permission tables is sufficient. ReBAC tooling adds real operational complexity — graph traversal infrastructure, consistency management, cycle detection — that is not justified for simple permission structures.

The inverse query deserves emphasis. "What can this user access?" is one of the genuinely hard problems in ReBAC. In an ACL system, answering it requires scanning all resources — expensive at scale. In a well-modelled ReBAC graph, you can traverse outward from the user node and collect all reachable objects. But as the graph grows, this traversal must be carefully indexed and cached. It is solvable, but it is not free.

The Hidden Complexity of ReBAC

ReBAC is powerful, but it introduces challenges that other models do not have. Anyone implementing it should understand these before committing to the model.

Graph traversal performance. Checking access requires traversing a graph that may be many hops deep. A user who is a member of a group that is a member of another group that owns a folder that contains a file involves four hops. At Google's scale, trillions of such traversals per day must complete in milliseconds. This requires sophisticated caching, indexing, and careful query planning. Even at smaller scales, naive graph traversal will produce unacceptable latency.

Consistency. When a relationship changes — Bob removes Carol's access — that change must be reflected in access checks promptly. But in a distributed system, propagating changes across cached decisions is difficult. Most systems can accept some degree of eventual consistency for authorization, but this must be an explicit design decision rather than an accidental one.

Cycle detection. Relationships can create cycles. Alice shares with Bob; Bob shares with Alice. When checking access, the traversal algorithm must detect and break these cycles to avoid infinite loops. This is a standard graph problem, but it must be deliberately built into the implementation.

Revocation and propagation. When a relationship in the middle of a long chain is removed, all downstream permissions derived from that relationship should be revoked. If Alice removes Bob's editor access, Carol (who got view access through Bob) should lose access automatically. Computing and propagating these changes efficiently — especially in large, deeply nested permission graphs — is one of the harder operational challenges in production ReBAC systems.

Debuggability. When access is denied, why? In RBAC, the answer is usually "you lack role X." In ReBAC, the answer is "there is no path from you to this resource through relationships that collectively grant read permission." This is harder to explain to end users and harder for administrators to trace. Good tooling for visualising and explaining the permission graph is not optional — it is a requirement for operating a ReBAC system at scale.

ReBAC in the Authorization Stack

ReBAC does not sit alone — it occupies a specific layer in a complete authorization architecture. A typical flow looks like this:

1. Authentication establishes who the user is.
2. RBAC checks whether the user's organisational role grants baseline access.
3. ABAC evaluates context — time of day, device, classification level, and similar attributes.
4. ACL checks for explicit per-resource grants or denials.
5. ReBAC evaluates the relationship graph to determine whether a path exists that grants the requested permission.
6. A final decision is made: allow or deny.

In practice, these layers are not always distinct systems — a well-designed policy engine can evaluate all of them through a unified rule set. And in some domains, ReBAC effectively replaces ACLs rather than sitting alongside them: instead of maintaining flat lists on each resource, the system maintains a relationship graph and derives access dynamically. The key point is that each layer addresses a different kind of authorization question, and most production systems need more than one.

What You Should Take Away

After reading this article, you should understand that ReBAC is an authorization model where permissions are derived from relationships between entities and flow through transitive chains. It is the natural model for any system where users share resources with each other.

More specifically, you should be able to explain what ReBAC is and why it exists — it solves the problem of dynamic, individual, transitive sharing that RBAC, ABAC, and ACLs cannot handle cleanly. You should understand the core concepts: typed relationships, transitive chains, inheritance versus delegation, and graph-based authorization. You should recognise where ReBAC naturally emerges — document collaboration, social networks, org hierarchies, project management — because understanding the pattern helps you identify when you need it. You should know when not to use it: simple role-based systems with no sharing do not need graph traversal infrastructure. And you should appreciate the hidden complexity: performance, consistency, cycles, revocation propagation, and debuggability are all harder in a graph-based model than in a flat one.

Google Zanzibar — and its open-source descendants SpiceDB, Ory Keto, and OpenFGA — are the reference points for what production ReBAC looks like. If you are designing a system that needs it, studying Zanzibar's architecture is time well spent.

The Shared Document Revisited

Let us return to where we started.

You created a document, owned it, and shared it with three colleagues. They shared it further. Those people shared it further still. The document now has dozens of viewers, editors, and commenters connected through a web of sharing relationships.

No one created a role called "CanViewDocumentX." No one added ACL entries for every person. No one wrote a policy about "users who were shared with by someone who was shared with by the owner."

The system stored the relationships. When David asks to view the document, the system traverses the graph and finds the path: David was shared with by Carol, who was shared with by Bob, who was shared with by you. The path grants view access because each link in the chain carried that permission.

When you remove Bob's access, the path from Carol and David to the document is broken. They lose access automatically. No cleanup required.

This is ReBAC. Not roles. Not attributes. Not lists. Connections. The web of relationships that forms naturally when people collaborate — made into the foundation of access control.

In any system where users share resources with each other, where permissions flow through chains, where access is dynamic and relationship-driven, ReBAC is not a luxury. It is the right tool.