Primary
Zanzibar: Google's Consistent, Global Authorization System
The canonical source about ReBAC on a global scale and the tuple relationship model.
The authorization model determines how exactly the system makes the access decision. In practice, teams combine several approaches: RBAC as a base layer, ABAC for context and exceptions, ReBAC for graph-shaped collaboration, ACL as a local mechanism at the object level.
Canonical visualization of models
ACL
Rights are stored next to the resource as a list of subjects and permissions.
Comparison of models
| Criterion | ACL | RBAC | ABAC | ReBAC |
|---|---|---|---|---|
| Unit of Policy | Entry per resource | Role | Rule | Relation in the graph |
| Granularity | Very accurate, but local | Average | High | High on the graph |
| Access changes | Expensive on larger sets | Cheap via role mapping | Via Policy/Attributes | Through new relation tuples |
| Explainability | High | High | Average | Medium, need explain API |
| Platform complexity | Low | Low-medium | Medium-high | High |
| Typical scale | Local systems | Enterprise/B2B | Regulated domains | Collaboration at scale |
ABAC
NIST SP 800-162
Practical recommendations on the policy model and attributes for ABAC.
Limits of applicability
ACL
When suitable: Object storage, file systems, small isolated domains with an explicit owner rule.
Where does it start to hurt: Large multi-tenant systems: mass rights changes are too expensive.
Border: Use it as an edge model next to a resource, but not as a single global policy for the entire company.
RBAC
When suitable: Internal platforms, B2B SaaS, mature org structures with clear job functions.
Where does it start to hurt: Contextual decisions (geo/time/risk) and object exceptions per item.
Border: Basic model for most systems. Strengthen with ABAC predicates or ACL exceptions.
ABAC
When suitable: Domains with compliance: finance, healthcare, govtech, where context and data classification are important.
Where does it start to hurt: Teams without governance for attributes and without a testable policy lifecycle.
Border: We need a strict dictionary of attributes, audit policy changes and tools to explain/trace solutions.
ReBAC (Zanzibar)
When suitable: Collaborative products: documents, repositories, workspaces, complex shared graphs.
Where does it start to hurt: Small systems where the relationship graph does not justify the infrastructural complexity.
Border: Justified when there are a large number of relationship checks and the need for a consistent global AuthZ service.
In 2026, a typical production approach: RBAC as a framework, ABAC as context conditions, ReBAC for shared objects, ACL as local override on a resource.
Typical antipatterns
Make one 'god-role admin' and try to close all access scenarios with it.
Mix business attributes and security attributes without owner and without data contract.
Build ReBAC without explainability: users do not understand why access is available or not.
Leave rights after org changes (offboarding/role change) without automatic revoke.