Relationship-Based Access Control (ReBAC)
Authorization model based on relationships between subjects and objects (e.g., owner, editor, viewer). Popularized by Google's Zanzibar paper. Access is resolved through graph traversal.
Relationship-Based Access Control (ReBAC) is an authorization model where access decisions are based on the relationships between subjects and objects. Instead of "what role does this user have?", ReBAC asks "how is this subject related to this object?" — for example, "is Alice a viewer of this document?"
Zanzibar and ReBAC
ReBAC was popularized by Google's Zanzibar paper (2019), which describes a global authorization system serving billions of users across Google's entire product suite. Zanzibar stores relationship tuples (e.g., document:budget owner user:alice) and resolves access through graph traversal.
When ReBAC beats RBAC
- Access depends on ownership ("users can edit their own documents")
- Ad-hoc sharing ("share this file with Carol for 7 days")
- Hierarchical access (folder permissions flow down to documents)
- Multi-hop relationships (team → project → resource)
WardenAuth's ReBAC support
WardenAuth supports relationship tuples alongside RBAC and ABAC — all from the same API. Read the ReBAC vs RBAC deep-dive.
Related terms
Authorization that evaluates permissions at the individual resource or action level, rather than broadly by user type or role.
Role-Based Access Control (RBAC) grants permissions via roles. Attribute-Based Access Control (ABAC) evaluates arbitrary attributes (user, resource, environment) against policy rules.
Google's global authorization system described in their 2019 paper. Uses relationship tuples and namespace configuration for ReBAC at planetary scale with single-digit millisecond latency.