Concepts · authorization models

From RBAC to ReBAC: one more column.

Relationship-based access control is usually introduced through Google's Zanzibar paper, which is accurate but not especially clarifying if you already run role-based access control and want to know what actually differs. The difference is one term in what gets stored. This page works through three escalating requirements to show where that term starts to matter.

RBAC stores

(subject, permission)

"Alice can edit." Which thing she can edit lives in application code, or is encoded into the role's name.

ReBAC stores

(subject, relation, object)

"Alice is editor of document:spec_v4." The object is part of the record, so the database can be asked questions about it.

RBAC

1roles required

Role table

ReBAC

3relationships written

Relationships

The schema

Written once

Scope

When RBAC is the right answer

Relationship-based authorization adds a service, a schema, and a consistency model to reason about. Those costs are real, and plenty of systems never encounter the problems they solve.

RBAC is likely sufficient when

Permissions are uniform across objects. If every user with a role can act on every object of that type, the object adds nothing to the decision and storing it is overhead.
Users don't share resources with each other. Sharing, delegation, and ownership are what generate per-object grants. Without them, roles stay stable.
There is no hierarchy to inherit through. Folders, teams, org units and parent-child resources are where traversal earns its keep. A flat resource model rarely needs it.
The role count is stable over time. The signal to watch is not how many roles you have, but whether the number grows when you add customers, regions, or resources rather than when you add features.

The problems ReBAC exists to solve

Roles whose names contain object identifiers. doc_4471_editor is an access control list stored in a table with no index for the object it refers to.
Permissions that must inherit recursively. Nested folders, sub-teams, and resource hierarchies where a grant at one level has to flow down an arbitrary depth.
Grants that expire or apply conditionally. Time-bound access, and access that depends on request context, have no natural home in a role assignment.
Needing to enumerate access. "What can this user see" and "who can see this" as first-class queries rather than reports assembled in application code.
Correctness under change. Once permission data is cached or embedded in tokens, a revocation is not immediate — the window between revoking access and that revocation taking effect is a real exposure.

Where to read more

SpiceDB documentation

Schema language reference, API surface, and deployment guides. authzed.com/docs

SpiceDB on GitHub

The open-source implementation, issues, and examples. github.com/authzed/spicedb

The Zanzibar paper

Google's original description of the design this model comes from, including the consistency mechanism.

From RBAC to ReBAC: one more column.

RBAC

ReBAC

The schema

Two questions that need the object in the record

Which documents can Alice view?

Who can view spec_v4?

ReBAC is a superset of RBAC

A role table