Zanzibar-Style Authorization Explained for Developers

Why Roles Stop Working and What Replaces Them

Almost every application starts with roles. A user is an admin or an editor or a viewer, you check the role, you move on. It works beautifully right up until the day someone asks a question your role table cannot answer: can this user edit this specific document, because it lives in a folder shared with a team they were invited to by someone who themselves only had commenter access?

That question is not about who the user is. It is about how the user is connected to the thing. And that shift — from attributes of a person to relationships between entities — is what relationship-based access control, or ReBAC, exists to model. This guide walks through where the idea came from, when it is worth adopting, and what the open-source landscape looks like in 2026.

Quick Picks

• Just starting out, simple app: stay with role-based access control. Do not add an authorization service to solve a problem you do not have yet
• Nested resources, sharing, or multi-tenant SaaS: a Zanzibar-style ReBAC system is the right shape, and adopting it early is far cheaper than retrofitting
• Want to self-host and own the data: Permify and SpiceDB are the two open-source implementations most people end up comparing
• Need authorization across several services at once: centralize it. The failure mode of scattered permission checks is that they drift apart silently

What Is Google Zanzibar?

Zanzibar is Google's internal authorization system, described publicly in a paper presented at USENIX ATC in 2019. It is the thing that decides whether you can open a particular Google Drive file, watch a particular YouTube video, or touch a particular Cloud resource. The published figures give a sense of the scale it was built for: trillions of access control entries, millions of authorization checks per second, 95% of checks answered in under 10 milliseconds, and availability above 99.999%.

The design idea is simpler than the scale suggests. Zanzibar stores authorization as a graph of typed relationships, written as tuples in the form of subject, relation, object. "User alice is an editor of document readme." "Group engineering is a member-set of folder specs." "Document readme is a child of folder specs."

An authorization check then becomes a graph question: does subject U have relation R with object O? The system walks the relationships, following the edges, until it either finds a path that grants the permission or exhausts the options.

How ReBAC Differs From RBAC and ABAC in Practice

Three models get compared constantly, so it is worth separating them cleanly.

• RBAC — role-based. Permissions attach to roles, roles attach to users. Simple to reason about, simple to audit. Breaks down when permissions need to vary per resource, because you end up inventing roles like "editor-of-project-47" and your role table becomes a relationship table wearing a disguise
• ABAC — attribute-based. Permissions are computed from attributes of the user, the resource and the context — department, classification level, time of day, IP range. Very flexible, but hard to answer the reverse question: who can access this document? You often have to evaluate every user to find out
• ReBAC — relationship-based. Permissions derive from the graph of connections. Naturally handles nesting and sharing, and answers both directions — what can this user reach, and who can reach this resource

Two features do most of the work in a ReBAC model. Implication means one relation automatically grants another: if you can write, you can read, without anyone writing that down twice. Inheritance means permissions flow down the hierarchy: grant someone write access on a folder and every resource inside it inherits that relation, so you are not maintaining thousands of individual grants that drift out of sync.

In practice, most real systems end up as a hybrid. Permify, for example, supports RBAC, ReBAC and ABAC in one policy language, so you can express "an editor of this document, unless the document is locked, and only during business hours" without bolting three systems together.

When Should You Actually Adopt a Dedicated Authorization Service?

The honest answer is: later than vendors suggest, and earlier than most teams manage.

Signals that you are ready:

• The same permission rule has to hold across more than one service, and you have already copy-pasted it at least once
• You are building multi-tenant software where each tenant needs isolated, and possibly differently shaped, permission rules
• Your resources nest — organizations contain projects contain documents — and access flows down that tree
• Someone has asked for an audit of who can see a given record, and answering it required writing a one-off script
• Your permission checks live inside database queries, so changing a rule means changing SQL in a dozen places

Signals that you should wait:

• A single application, a handful of roles, and no sharing model
• Permissions that have not changed in a year
• A team small enough that everyone knows every check by heart

The cost of adopting too early is real: an extra service to run, an extra network hop on the request path, and a policy language to learn. The cost of adopting too late is worse, because by then the permission logic is smeared across an entire codebase and extracting it is archaeology.

What Are the Open-Source Options in 2026?

Two projects dominate the self-hosted conversation, both explicitly modeled on the Zanzibar paper.

• Permify. An open-source authorization service under the AGPL-3.0 license, and a Cloud Native Computing Foundation member. It exposes both gRPC and REST APIs, runs from a Docker container, supports RBAC, ReBAC and ABAC in one schema language, and isolates rule sets per tenant. The project reports check latencies averaging around 21 milliseconds under heavy load, which is the right order of magnitude for an in-request call
• SpiceDB. The other widely deployed Zanzibar implementation, with a mature consistency model and a large operator community

Managed services exist too, and for a small team the operational argument for one is strong. The thing to check before committing either way is data residency: an authorization service sees the shape of your entire object graph, which is close to a map of your business. Where that graph lives is a security decision, not just a procurement one.

How Does This Fit a Zero-Trust Architecture?

Zero trust is often described as "never trust, always verify," which is true but unhelpfully abstract. Concretely, it means every request is authorized on its own merits rather than because it arrived from inside a trusted network segment. That only works if authorization is something you can actually call, consistently, from anywhere — which is exactly what a centralized authorization service provides.

The pressure has increased as software has started making requests on a user's behalf. When an agent acts for a person across several systems, the permission question stops being "is this session allowed" and becomes "is this action, on this resource, allowed for the human this agent represents right now." A permission model expressed as a graph of relationships answers that far more cleanly than one expressed as a static role. It also pairs naturally with short-lived, revocable credentials — see our coverage of the ORKS revocable API key standard and the broader self-hosted LLM server security guide.

Common Mistakes Worth Avoiding

• Modeling permissions instead of relationships. Store the fact that someone is an editor of a folder, not the derived fact that they can edit forty documents. Let the system derive
• Forgetting the negative case. Graph traversal is good at finding a path that grants access. Make sure your model can also express revocation, and test it
• Putting the check in the wrong place. An authorization service is not a replacement for authentication, and it is not an input filter. It answers one question well
• Skipping the cache design. Zanzibar's performance comes substantially from careful caching and a consistency token scheme. Any implementation you pick will have its own answer to stale reads — understand it before you are debugging it
• Ignoring the audit path. The reason to centralize is partly so you can answer questions later. Log the checks, not just the grants

Where to Start

If you have read this far and recognized your own system in the "ready" list, the cheapest first move is not a migration. It is an inventory: write down every place in your codebase that makes an access decision. Most teams are surprised by the count, and that list is the actual scope of the work. Model one resource type in a ReBAC schema, run it alongside the existing checks, and compare the answers before you cut anything over.

More defensive tooling coverage is in our AI security section.

Sources: Permify on GitHub — accessed September 14, 2026; Help Net Security — September 14, 2026; Authzed SpiceDB documentation on Zanzibar — accessed September 14, 2026.