ReBAC

How it works

ReBAC (Relationship-Based Access Control) decides access by traversing relationships in a graph: a user can act on a resource if a path of relationships connects them, such as "user is a member of a team that owns the folder that contains this document." It was popularized by Google's Zanzibar system, which powers sharing across Google products, and it is the model behind open-source authorization engines like OpenFGA and SpiceDB. Permissions are computed by following relationship tuples (subject, relation, object) rather than by matching a role or evaluating standalone attributes.

When it matters

ReBAC matters for applications built around sharing, hierarchy, and nested ownership: documents shared with specific people, folders that inherit permissions, organizations with teams and sub-teams. These "who can access this specific object, and why" questions are exactly what RBAC handles poorly and what ABAC expresses awkwardly. If your product looks like Google Docs, GitHub, or Notion in its sharing model, ReBAC is likely the right fit.

Common misconceptions

• "ReBAC is only for hyperscalers." Zanzibar-inspired open-source engines make it practical for startups now.
• "ReBAC replaces roles entirely." Roles often still exist as relations within the graph; ReBAC generalizes rather than discards them.
• "A graph is overkill." For per-object sharing at scale, modeling relationships is simpler and more correct than accumulating roles or attribute rules.