<aside> 🔐

Authzed SpiceDB — Fine‑Grained Authorization (Zanzibar for your systems)

A premium, production-minded guide to SpiceDB: the Google Zanzibar-inspired authorization database for relationship-based access control (ReBAC) — with modern patterns for Java + Spring Boot, microservices, consistency, and ops.

</aside>

<aside> 🎯

What it solves

Stop scattering if/else authorization logic across services. Centralize the question: “Can subject X do action Y on resource Z?” using a live relationship graph.

</aside>

<aside> ⚡

Why it’s different

Permissions are computed at query time from the live graph (not static policy files), enabling correctness at scale.

</aside>

<aside> 🏗️

How to use it

Treat SpiceDB as the PDP. Every microservice is a PEP that enforces decisions before executing business actions.

</aside>

The mental model (in one paragraph)

SpiceDB is not an authentication library and not “just RBAC”. It’s a relationship database for fine-grained authorization — designed to answer permission checks with single‑digit millisecond latency even at massive scale, inspired by Google’s Zanzibar system.

When to use SpiceDB (vs OPA / Casbin / custom RBAC)

System	Model	Live relationship graph?	Best for
SpiceDB	ReBAC (+ RBAC + ABAC)	✅ Yes	Per‑resource authorization at scale (multi‑tenant SaaS, content, shared workspaces)
OPA / Rego	ABAC (policy-as-code)	❌ No	Gateway/coarse rules, k8s admission, platform controls
Casbin	RBAC/ABAC embedded	❌ No	Single-service apps, low complexity
Custom DB RBAC	RBAC	Partial	Simple apps (but tends to break under growth and microservices)

Core vocabulary (you’ll hear these everywhere)

<aside> 📚

Object type (definition): user, document, folder, org

Relation: viewer, editor, owner, member

Permission: computed boolean like can_view

Relationship: instance like document:budget#viewer@user:alice

PEP: app/service enforcing decisions

PDP: SpiceDB (the decision engine)

ZedToken: consistency cursor (Causality) to avoid stale decisions

</aside>

Schema: the foundation (with a production-grade example)

<aside> 🧠

Design principle: relations are your “data model” (breaking changes); permissions are your “views” (safe to evolve). Design relations conservatively; permissions expressively.

</aside>

A multi-tenant document platform schema (representative)

/** Example: A multi-tenant document management system */

/** user represents an authenticated principal */
definition user {}

/** organization groups users into tenants */
definition organization {
    relation member: user
    relation admin: user

    permission is_member = member + admin
}

/** team belongs to an org; has members */
definition team {
    relation org: organization
    relation member: user | team#member

    permission has_membership = member
}

/** folder groups documents; can be nested */
definition folder {
    relation org: organization
    relation parent: folder
    relation viewer: user | team#member
    relation editor: user | team#member
    relation owner: user

    permission view   = viewer + editor + owner + parent->view
    permission edit   = editor + owner + parent->edit
    permission delete = owner
    permission manage = owner
}

/** document is the primary protected resource */
definition document {
    relation org:    organization
    relation folder: folder
    relation owner:  user
    relation editor: user | team#member
    relation viewer: user | team#member

    permission can_view   = viewer + editor + owner + folder->view + org->is_member
    permission can_edit   = editor + owner + folder->edit
    permission can_delete = owner
    permission can_share  = owner + folder->manage
}