ReBAC vs. RBAC: When You Need Relationship-Based Access Control
Google Zanzibar popularized relationship-based access control for "who can access this document" problems. We compare ReBAC and RBAC, show where roles fall short, and explain why most teams need resource-scoped RBAC before reaching for a graph.
“Can Alice view this specific document?” sounds like an RBAC question, but it often is not. If the answer depends on whether Alice owns the document, was shared on it, or belongs to a team that owns the parent folder, you are asking a relationship question. That is the domain of ReBAC — relationship-based access control, popularized by Google’s Zanzibar paper.
What ReBAC Is
ReBAC models access as a graph of relationship tuples: (object, relation, subject). Access is resolved by traversing relationships, including inherited ones (a viewer of a folder is a viewer of its documents).
document:budget-q3 owner user:alice
document:budget-q3 viewer group:finance
group:finance member user:bob
folder:2025 parent document:budget-q3 // inheritance edgeTo check “can Bob view budget-q3?” the engine walks: Bob → member of finance → viewer of budget-q3 → allowed.
Where RBAC Alone Falls Short
- Ownership. “Users can edit documents they created” is per-instance, not per-role.
- Sharing. Ad-hoc grants (“share this doc with Carol”) do not map to job functions.
- Nesting. Access that flows through folders, teams, and orgs is a graph traversal.
RBAC vs. ReBAC
| Dimension | RBAC | ReBAC |
|---|---|---|
| Model | Subject → Role → Permission | Graph of relationship tuples |
| Best question | "What job function is this?" | "How is this subject related to this object?" |
| Per-instance access | Awkward (role explosion) | Native |
| Inheritance / nesting | Manual | Built-in via graph traversal |
| Auditability | High | Requires graph queries |
| Operational complexity | Low | Higher — tuple store + traversal engine |
Do You Actually Need ReBAC?
Most applications think they need ReBAC but actually need resource-scoped RBAC. If your access rules are “members of a workspace can edit that workspace’s resources,” a scope boundary plus roles handles it cleanly — no graph engine required. Reach for ReBAC when you have genuine deep, arbitrary nesting and ad-hoc per-object sharing, like Google Docs or GitHub.
How WardenAuth Models Ownership
WardenAuth uses scopes as tenant/workspace boundaries and resource-scoped permissions to cover the vast majority of “access to my workspace’s data” cases without the operational weight of a full Zanzibar deployment. For ownership, you attach the owner check as an attribute condition on top of the role gate — the hybrid approach from our RBAC vs. ABAC guide. Start free to model your first scope.