RBAC vs ABAC vs ReBAC: Choosing an Authorization Model

Three models, briefly

The choice between them is not aesthetic. Each model has scaling and authoring characteristics that determine which scenarios it handles cleanly and which it makes expensive.

RBAC: roles that aggregate permissions

RBAC is the model most teams start with: define a set of roles (admin, editor, viewer), assign permissions to roles (admin can delete, editor can write, viewer can read), and assign roles to users. At check time, the system answers "does this user have a role that grants this permission?"

Alice → role: admin → permissions: [users.delete, billing.read, ...]
Bob   → role: editor → permissions: [posts.write, posts.read]

RBAC works well when:

• The role count stays small (5–10 roles is typical, 20 starts to feel awkward, 50+ is unmaintainable).
• Permissions don't need to vary per resource instance.
• Role assignment is the right abstraction for the buyer (admin assigns roles in a console).

RBAC breaks down when teams start creating roles like editor-of-project-X or viewer-of-document-Y to model resource-specific permissions. That's role explosion, and it's the signal to add ReBAC or move to it.

ABAC: policies that evaluate attributes

ABAC moves the decision from "does the user have a role" to "does this policy evaluate true for these attributes." Policies are expressed in a language (XACML historically; Rego via OPA in modern deployments) and consider attributes of the subject, resource, action, and environment.

allow if {
  input.subject.department == input.resource.department
  input.subject.clearance >= input.resource.classification
  time.now_ns() >= input.resource.releaseDate
}

ABAC handles arbitrary logic that doesn't fit role aggregation cleanly: time-of-day rules, classification-versus-clearance, geographic restrictions, dynamic conditions. The price is policy authoring complexity, Rego is a real language, policy edits often require dedicated review, and policy mistakes can be subtle (allow-deny precedence, missing default-deny).

ABAC fits well when:

• Policy logic genuinely doesn't reduce to roles.
• The team has policy-authoring competence (security engineers, compliance team, dedicated authz reviewers).
• The decision needs to consume context that role assignment can't capture.

ABAC fits poorly when:

• The use case is "Alice can edit Project X", that's relationships, not attribute logic.
• The team isn't ready for Rego / XACML authoring.

ReBAC: relationships in a graph

ReBAC was named in academic literature long before Zanzibar, but the 2019 Google paper is the reason the model is mainstream in 2026. Permissions are modeled as relationships between subjects and objects, expressed as triples:

project:acme-launch#editor@user:alice
document:roadmap-v3#parent@project:acme-launch
team:engineering#member@user:bob

Authorization checks traverse the graph: "Does Alice have edit permission on document:roadmap-v3?" → walk from user:alice through her relationships to find a path that grants the permission. Inheritance is expressed as schema rules: "Edit on a project implies edit on its child documents."

ReBAC fits well when:

• The application has resources users hold permissions on (projects, documents, repos, channels, files).
• Permissions inherit through a containment hierarchy.
• Sharing is a first-class operation, granting Alice access to one resource without changing her role.
• The system needs to answer "which resources does Alice have access to" (reverse queries).

The Zanzibar architecture additionally handles the consistency model (zookies) so that authorization decisions can be cached across geo-distributed datacenters without staleness violating user expectations.

When teams compose models

Most mature B2B SaaS in 2026 run a hybrid:

• RBAC for coarse policy, admin vs member vs billing-only at the org level.
• ReBAC for resource-level permissions, who can edit which project, who can view which document.
• ABAC for the edge cases, region-locked resources, business-hours-only operations, classification policies.

The composition isn't theoretical. WorkOS ships RBAC primitives plus WorkOS FGA (Zanzibar-style ReBAC). Auth0 ships role-based authorization plus Auth0 FGA. Authress ships ReBAC as the design center with RBAC convenience on top.

Implementation choices in 2026

For RBAC, every CIAM in this index ships role primitives, the choice is bundled with the CIAM choice, not a separate evaluation. ReBAC and ABAC are the dimensions where standalone authz vendors compete: which engine handles fine-grained per-resource permissions at scale, and which policy language fits the team's authoring competence. The 2026 production-ready picks are below; for most B2B SaaS, the question collapses to "which Zanzibar implementation matches our stack."

For ReBAC at scale, the production-ready Zanzibar implementations are:

• OpenFGA, CNCF Sandbox project, originated at Auth0/Okta, broadly vendor-neutral.
• SpiceDB (Authzed), commercial Zanzibar implementation, also OSS.
• Permify, OSS Zanzibar with growing adoption.
• Ory Keto, bundled with the Ory stack.
• Auth0 FGA, managed, tightly integrated with Auth0 CIAM.
• WorkOS FGA, managed, bundled with WorkOS B2B SaaS auth.

For ABAC, OPA (Open Policy Agent) is the dominant 2026 choice, with Rego as the policy language. Casbin is the alternative for teams preferring a smaller surface and library-style integration.

Vendor support snapshot

Among full-platform CIAM, native ReBAC support clusters around: Auth0 FGA, WorkOS FGA, Authress (the only CIAM in this index built around ReBAC as the design center), Ory Keto, and Casdoor (via Casbin). Everything else either ships RBAC plus a recommendation to pair with OpenFGA / SpiceDB / Permify, or ships RBAC plus ABAC and considers ReBAC out of scope.