What is Google Zanzibar authorization and how does it actually work?

The Direct Answer: What Google Zanzibar Is

Google Zanzibar is Google's internal authorization system, first described publicly in a 2019 research paper titled "Zanzibar: Google's Consistent, Global Authorization System." It is a centralized service that answers one question at enormous scale: can user X perform action Y on resource Z? Zanzibar stores relationships between users and objects as tuples — for example, "user:anne is an editor of document:readme" — and evaluates those stored relationships against access-control policies to return allow or deny decisions. Google reports that Zanzibar handles tens of billions of authorization checks per day across products like Drive, Docs, YouTube, Calendar, Maps, and Cloud IAM, with a database holding trillions of relationship tuples.

Also worth reading: What is agentic AI identity lifecycle management and how do enterprises actually implement it in 2026? · What is the dual-LLM pattern for agent security, and can it actually protect AI agents from prompt injection? · What is an AI concept generation innovation lab platform and how do companies actually use one?

The key insight behind Zanzibar is that permissions in modern applications are relational rather than role-based. A file might be shared with a specific person, inherited from a parent folder, granted through a group membership, or accessible because of a domain-wide policy. Traditional RBAC (role-based access control) systems struggle to express this web of inheritance. Zanzibar models it directly using a graph of relationships plus a configuration language called the namespace config, which defines how object types relate to each other and which rules govern them.

It matters to understand what Zanzibar is not. It is not authentication (that's handled by identity providers), it is not a full IAM suite, and it is not open source itself. Google published the paper and the design principles, but the production system remains proprietary. Everything else in this article builds on that distinction, because most of the confusion around "Zanzibar" today comes from people conflating the original system with its open-source reimplementations.

Why Google Built It: The Problem Zanzibar Solves

Before Zanzibar, Google's products each maintained their own permission logic, which produced inconsistent behavior and duplicated engineering effort. When Drive needed to know whether a user could comment on a shared doc, it had to reconcile sharing settings, group memberships from multiple directories, folder inheritance chains, and link-sharing grants — all while those facts changed constantly. A single check could require resolving hundreds of thousands of group memberships, because some Google employees belong to very large groups, and nested groups compound the problem exponentially.

Three hard requirements shaped the design. First, correctness under change: when someone's access is revoked, it must take effect quickly everywhere, not after a cache refresh hours later. Second, low latency: authorization checks sit on the hot path of every page load and API call, so p95 latency targets are measured in milliseconds even when evaluating deep inheritance graphs. Third, horizontal scalability: the system must scale to trillions of tuples spread across data centers worldwide without a single point of failure.

The paper describes a consistency model built around two mechanisms: zookies (a portmanteau of ZooKeeper and cookies) and relation tuple snapshots. A zookie is a token representing a point-in-time snapshot of the database; clients pass it back on subsequent writes so that a read-your-writes guarantee holds even in a globally replicated, eventually consistent store. Without this, you get the classic bug where a user revokes a share, immediately reloads the page, and still sees the old grant — or worse, where stale replicas let a revoked user keep editing. Zanzibar's designers treated this as a first-class problem, and any reimplementation that skips it will eventually produce security bugs that are maddening to reproduce.

How the Model Works: Tuples, Namespaces, and Rewrites

At the storage layer, Zanzibar records everything as relation tuples of the form object#relation@user. Examples include doc:readme#owner@user:anne, folder:company-policies#viewer@group:employees#member, and doc:q3-report#editor@doc:q3-report#parent. That last example shows inheritance: the report's editors derive from its parent folder's relations. Relations themselves can be users, groups, or other objects, which turns the whole permission model into a directed graph.

The namespace configuration defines, per object type, which relations exist and how they're computed. Rewrite rules support three operations: union (any of these grants access), intersection (all must hold), and exclusion (this holds unless that does). A typical rule reads like: "writer = owner + editor" or "can_delete = owner - suspended_user." These rules are declarative, versioned, and testable, which is a genuine improvement over permission logic buried in application code where nobody can audit it holistically.

Evaluation happens through graph traversal. When a check arrives — "is user:bob a viewer of doc:x?" — the server expands the namespace rules into a subgraph and walks it, consulting indexes over the tuple store. Because real-world graphs can be pathologically deep (the paper cites cases requiring hundreds of thousands of group expansions), Zanzibar uses caching, precomputed intermediate results, and heuristics like checking the cheapest branches first. The paper reports median check latency around 3 milliseconds and 99th-percentile latency under 100 milliseconds, which is respectable given the complexity involved.

A practical consequence worth noting: modeling your domain well is harder than running the software. Teams routinely spend weeks deciding whether "billing admin" should be a relation on an account, a group, or a role on individual invoices. Get the ontology wrong and every downstream check becomes convoluted. This is where concept-generation and design work pays off before any code is written — mapping resources, actions, and inheritance paths on paper first saves painful migrations later.

Open-Source Implementations: SpiceDB, OpenFGA, Ory Keto, and Others

Since the 2019 paper, several open-source projects have implemented the Zanzibar model, and they differ meaningfully in maturity, licensing, and operational profile. Auth0's OpenFGA (donated to the Cloud Native Computing Foundation in 2024) grew out of Auth0 FGA and emphasizes developer ergonomics with a friendly DSL. SpiceDB, from Authzed, is probably the closest architectural analogue to the original, written in Go with a gRPC API and strong consistency guarantees including its own zookie equivalent. Ory Keto, part of the Ory open-source identity stack, aims for Zanzibar compatibility within a broader IAM platform, though its maintainers have been candid that full parity took years and some features remain partial. There are also smaller efforts like Permify and Warrant targeting simpler deployment scenarios.

None of these is a drop-in replacement for Google's internal system, and none publishes benchmarks directly comparable to the paper's numbers. If your workload involves fewer than a few million tuples and modest check rates, all three will serve fine. Past roughly hundreds of millions of tuples with heavy group nesting, differences in caching strategy and datastore backends start to matter, and you should benchmark against your own access patterns rather than trusting vendor claims.

Zanzibar Versus RBAC, ABAC, and Policy Engines Like OPA

A common mistake is treating Zanzibar-style systems as a replacement for every authorization approach. They solve different problems. Classic RBAC assigns roles to users and roles to permissions; it's simple, auditable, and adequate when access patterns are coarse. ABAC adds attribute-based conditions (time of day, device posture, data classification). Policy engines like OPA (Open Policy Agent) evaluate rich policies written in Rego against arbitrary JSON input, which excels at infrastructure admission control and complex conditional logic but doesn't natively manage the relationship graph or provide the consistency guarantees Zanzibar was designed around.

In practice, mature platforms combine approaches: a Zanzibar-style engine for resource-level sharing decisions, plus attribute conditions layered on top, plus OPA or similar for infrastructure policy. Deciding which layer owns which decision is an architecture question, not a tooling question, and teams that skip it end up with three overlapping permission systems that disagree with each other.

Practical Steps to Adopt a Zanzibar-Style Architecture

Start by inventorying your authorization decisions. List every resource type, every action, and every way access is currently granted — direct shares, group membership, org hierarchy, public links, guest access. Most teams discover their real permission logic lives in scattered if-statements across services, undocumented and inconsistent. Consolidating that inventory into a written model is genuinely half the work.

Second, design your schema before touching code. Define namespaces for each resource type, enumerate relations, and write out rewrite rules. Then write test cases covering the awkward scenarios: nested groups, circular references, revocation mid-session, cross-tenant access attempts. Both SpiceDB and OpenFGA ship schema-validation and testing tools precisely because schema mistakes are the dominant failure mode.

Third, plan the migration path. You cannot flip a switch; existing permission data must be transformed into tuples, usually via a batch import, and you need a shadow-mode period where the new system runs alongside the old one so you can diff decisions and catch discrepancies. Budget weeks to months for this depending on data volume. Fourth, decide on consistency requirements explicitly: which checks need read-after-write guarantees (use consistency tokens) versus tolerating eventual consistency for speed. Finally, instrument everything — log every check, its latency, and its outcome — because authorization failures are silent until they become incidents, and you want the forensic trail before you need it.

For teams exploring product concepts in this space, the interesting frontier isn't replicating Zanzibar but building better tooling around it: visualization of permission graphs, automated anomaly detection on tuple changes, AI-assisted schema generation from existing codebases, and simulation environments that show exactly who can see what after a proposed policy change. Those gaps are where new products are finding traction in 2025 and 2026.

Common Mistakes and Failure Modes

The most frequent error is underestimating group explosion. Nested groups multiply evaluation cost non-linearly; a company with 50,000 employees and average group depth of five can generate millions of expansion steps for a single check unless caching and precomputation are configured properly. Teams migrating from simple RBAC often don't notice until p99 latency degrades under real load.

Second is ignoring consistency semantics. Developers new to the model frequently issue a write and immediately check the result without passing a consistency token, then file bugs about "missing permissions" that are actually stale reads. Conversely, demanding strong consistency on every check destroys the performance benefits that justified the architecture. Third is schema sprawl: adding ad-hoc relations whenever a new requirement appears until the namespace config becomes unmaintainable. Treat schema changes like database migrations — reviewed, versioned, tested.

Fourth is misjudging operational burden. Running a distributed authorization service means operating its datastore, monitoring replication lag, handling backup and disaster recovery, and staffing on-call expertise. Small teams frequently conclude after six months that a managed offering costs less than the engineering time spent self-hosting, even at higher sticker price. Fifth is assuming the model fits everything: high-frequency edge decisions (rate limiting, feature flags) don't belong in an authorization graph, and forcing them there creates latency problems no amount of tuning fixes.

Costs, Effort, and When to Act

Direct software costs vary widely. All major open-source implementations are free to self-host; your real costs are infrastructure (a replicated datastore such as PostgreSQL, CockroachDB, or Spanner-compatible databases) and engineering time. A realistic self-hosted implementation for a mid-size SaaS company runs roughly two to four engineer-months for initial setup and migration, plus ongoing maintenance of perhaps 0.25 to 0.5 FTE. Managed offerings — Authzed's SpiceDB Cloud, Auth0's FGA, Ory Network — typically price per authorization check or per tiered usage, commonly ranging from a few hundred dollars monthly at small scale to five figures at enterprise volume; exact pricing changes frequently enough that you should request current quotes rather than rely on published figures.

When should you adopt this pattern? Signals include: multi-tenant SaaS with per-resource sharing, permission logic duplicated across more than two services, customer complaints about inconsistent sharing behavior, compliance requirements demanding auditable access decisions, or scaling pain where permission checks dominate database load. If you have a single internal app with fifty users and three roles, RBAC in your existing database is cheaper and perfectly defensible — adopting Zanzibar there would be architecture tourism. The honest threshold is organizational complexity, not fashion. Companies that wait until permission chaos causes a security incident pay far more than companies that invest when the warning signs appear, but companies that adopt prematurely burn months on infrastructure they didn't need. Evaluate quarterly, decide deliberately.