Learn IAM
Learn IAM

Fine-Grained Authorization (Zanzibar Pattern): Relationship-Based Access Control

Fine-Grained Authorization (Zanzibar Pattern): Relationship-Based Access Control

When RBAC breaks down, you need relationships.

The “Zanzibar” pattern (popularized by Google and implemented by systems like SpiceDB/OpenFGA) models authorization as a graph of relationships between subjects (users/workloads) and objects (documents/projects/orgs), and answers questions like:

  • “Can user A view document D?”
  • “Who can administer project P?”
  • “Can this service account read customer C’s data?”

This is the backbone of many modern, multi-tenant products because it scales better than sprawling role matrices.

Core model

Objects, relations, and tuples

  • Object: the resource (e.g., doc:123, project:7).
  • Relation: the type of access on that object (e.g., viewer, editor, owner).
  • Tuple (relationship): a fact like doc:123#viewer@user:alice.

Those tuples form a graph you can traverse.

Computed relationships

Relations are often defined in terms of other relations:

  • editor implies viewer
  • owner implies editor
  • viewer can be granted via group membership

That’s how you avoid duplicating “role expansion” logic across services.

A practical example

Imagine a B2B SaaS product:

  • An org has members.
  • A project belongs to an org.
  • A document belongs to a project.

You want:

  • Org admins can manage all projects.
  • Project editors can edit documents in that project.
  • Document viewers can view that document.

A relationship model lets you encode that intent and answer checks consistently.

Where teams get stuck

  • Over-modeling early: start with the smallest set of objects/relations that match real product requirements.
  • No source of truth: decide whether relationships live in the authz store, your DB, or both—and how changes are propagated.
  • Revocation latency: understand your caching and invalidation story (especially for “remove access now”).

Checklist

  • Define resources and relations with a small, stable vocabulary.
  • Model inheritance/implication explicitly (don’t rely on app code).
  • Decide on caching + invalidation strategy.
  • Log decisions with enough context to debug “why was this denied?”

Where to go next