Fine-grained Authorization (FGA) Systems in 2026 — Zanzibar, SpiceDB, Permify, OpenFGA, Cerbos, Cedar, Oso Deep Dive

Prologue — Authorization is no longer a single if statement

The single most common phrase in a 2026 SaaS engineering channel is "authorization broke again." Capital One's breach made the entire industry paranoid about cloud IAM gaps, and GDPR-K (Korea's tightened PIPA), Japan's 2025 APPI amendment, and the EU AI Act all now demand auditable records of "who accessed what." The era of if user.role == "admin" ending the discussion is decidedly over.

The turning point was Google's 2019 USENIX ATC paper on Zanzibar. The shock was twofold. First, the fact that YouTube, Drive, Calendar, and the cloud console all share a single authorization backend. Second, that this backend expresses RBAC, ABAC, share links, folder inheritance, and group permissions through a single abstraction: a relationship. Seven years later, in 2026, the market has split into two camps: the Zanzibar-style (ReBAC) camp and the policy-language camp (OPA, Cedar, Cerbos).

This piece is the map. Where SpiceDB (AuthZed), OpenFGA (Auth0/Okta), Permify, Cerbos, AWS Cedar, Casbin, Oso, Ory Keto, Warrant, Aserto, and Topaz each sit, what trade-offs each has, and how Korean and Japanese enterprises have actually adopted them.

1. RBAC vs ABAC vs ReBAC — three eras of authorization

Authorization models have broadly diverged into three lineages.

Key insight: ReBAC generalizes both RBAC and ABAC. "A user is a member of a group; the group is a viewer of a folder; the folder contains a document" — that four-step relationship is the essence of authorization. A role in RBAC is just one node in this graph. An attribute in ABAC becomes a conditional relation in ReBAC.

The most common 2026 SaaS requirement is "share this board with an external guest, comments only." Modeling it in pure RBAC blows up the role count. So the market is converging on ReBAC plus conditional relations (which subsume ABAC).

2. Google Zanzibar — the paper that changed everything

The Zanzibar paper (USENIX ATC '19) packs the following into 19 pages.

• A single abstraction: the (object, relation, user) tuple. Example: (doc:readme, viewer, user:alice).
• Namespace/relation schemas to declare authorization models.
• Global consistency: external consistency guarantees built on Spanner.
• A novel consistency token, the Zookie, that lets clients say "at least this point in time."
• Cache-friendly snapshot reads plus a Leopard index to accelerate freshly written tuples.
• Check API with p99 < 10ms, handling tens of millions of requests per second.

The message the paper delivered to industry was clear: "authorization is actually a distributed-database problem." Permissions must be evaluated consistently over deep graphs (folder of folder of folder of share-group of member), which demands a consistency model normal databases do not provide.

3. Zanzibar internals — Zookie, snapshot read, Leopard

The three mechanisms most often cited from the paper.

Zookie (consistency token). If a client knows a user was just granted permission, it gets a Zookie and attaches it to the next Check. Zanzibar evaluates only state at or after the Zookie's timestamp. The design lets clients pick the trade-off between cache freshness and staleness explicitly.

Snapshot read. Most Check calls do not require strong freshness — they are ordinary lookups. Spanner's point-in-time snapshot reads maximize cache hit rate. Reported p99 cache hit > 90%.

Leopard index. Spanner is not optimized for graph traversal, so frequently evaluated group memberships (e.g. the full member list of the "googlers" group) are indexed separately as a kind of materialized view. New members are propagated asynchronously by Leopard.

Watch API. When a tuple changes, subscribers are notified. The channel for invalidating external caches (e.g. Akamai's permission cache).

4. The Zanzibar lineage — who built what

A scoreboard of how the industry split after the paper.

And the policy-language camp:

5. SpiceDB (AuthZed) — the most faithful Zanzibar implementation

SpiceDB is the implementation that Zanzibar paper-adjacent engineers advised on. As of 2026 it has become the de-facto standard for Zanzibar-style FGA. Apache 2.0 plus a commercial SaaS (Authzed Cloud) dual model.

# SpiceDB schema example: document sharing with folder inheritance
definition user {}

definition organization {
  relation member: user
}

definition folder {
  relation parent: folder
  relation owner: user
  relation viewer: user | organization#member

  permission view = viewer + owner + parent->view
  permission edit = owner + parent->edit
}

definition document {
  relation parent: folder
  relation owner: user
  relation viewer: user | organization#member

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

Core syntax: + is union, & is intersection, - is difference, and parent->view means "inherit the parent's view permission." A single file expresses RBAC, ABAC (with conditional relations), folder inheritance, and group permissions.

Performance: p99 < 10ms Check on a single node, scales horizontally to hundreds of thousands of Check/sec.

6. OpenFGA — Auth0/Okta's offering

OpenFGA is the Zanzibar implementation Auth0 (now Okta) open-sourced in 2022. It entered the CNCF Sandbox in 2023 and the graduation track in 2024. Strengths: a JSON-based model definition and rich SDKs across Node, Go, Python, Java, .NET, Ruby.

# OpenFGA model (DSL form, compiles internally to JSON)
model
  schema 1.1

type user

type organization
  relations
    define member: [user]

type folder
  relations
    define parent: [folder]
    define owner: [user]
    define viewer: [user, organization#member]
    define view: viewer or owner or view from parent
    define edit: owner or edit from parent

type document
  relations
    define parent: [folder]
    define owner: [user]
    define viewer: [user, organization#member]
    define view: viewer or owner or view from parent
    define edit: owner or edit from parent

The expressiveness is essentially identical to SpiceDB. The differences are the SDK ecosystem, hosting (Auth0 FGA as managed SaaS), and integration with the Okta Identity Cloud.

7. Permify — the open-source challenger

Permify is another Zanzibar implementation, built by a team out of Istanbul. The differentiators: first-class Postgres support as the backend, and a DSL slightly more concise than SpiceDB or OpenFGA.

# Calling the Permify Check API
curl -X POST 'http://localhost:3476/v1/tenants/t1/permissions/check' \
  -H 'Content-Type: application/json' \
  -d '{
    "metadata": {
      "schema_version": "",
      "snap_token": "",
      "depth": 20
    },
    "entity": {
      "type": "document",
      "id": "readme"
    },
    "permission": "view",
    "subject": {
      "type": "user",
      "id": "alice"
    }
  }'

The response is something like { "can": "CHECK_RESULT_ALLOWED" }. The snap_token mirrors SpiceDB's ZedToken and Zanzibar's Zookie.

8. Cerbos — policy-driven, not relationship-driven

Cerbos sits in a different camp from Zanzibar. It positions itself as a stateless Policy Decision Point (PDP) that does not store a relationship graph. Policies are authored in YAML, and context (subject, resource, environment) is provided by the caller on every request.

# Cerbos policy: leave-request approval
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "leave_request"
  rules:
    - actions: ['view']
      effect: EFFECT_ALLOW
      roles:
        - employee
      condition:
        match:
          expr: request.principal.id == request.resource.attr.ownerId

    - actions: ['approve']
      effect: EFFECT_ALLOW
      roles:
        - manager
      condition:
        match:
          all:
            of:
              - expr: request.resource.attr.status == "PENDING"
              - expr: request.principal.attr.department == request.resource.attr.department

Cerbos deploys nicely as a sidecar, policies are GitOps-friendly, and decisions are stateless so they cache easily. The weakness: ListObjects-style queries like "what folders can user:alice access" are weak.

9. AWS Cedar — a verifiable policy language

Cedar is the policy language AWS open-sourced in May 2023. It powers Amazon Verified Permissions (AVP), available directly in the AWS console. Cedar's most distinctive feature: policies are formally verifiable. A symbolic analyzer (in Rust) can prove "is this policy always safe?" of a Cedar policy.

// Cedar policy: document edit permission
permit (
  principal in Group::"engineering",
  action == Action::"editDocument",
  resource
)
when {
  resource has owner &&
  (principal == resource.owner ||
   principal in resource.editors)
};

forbid (
  principal,
  action == Action::"deleteDocument",
  resource
)
unless {
  principal in Group::"admins"
};

The default semantics are ABAC, but because principals and resources can be hierarchical via group membership, ReBAC is expressible too. Academic collaboration (with MIT and others) has produced peer-reviewed papers on the formal semantics of Cedar's verifier.

10. Casbin — the matrix-model approach with pluggable models

Casbin started in 2017 and supports 30+ language SDKs, making it the most generic authorization library out there. The differentiator: the model itself is a config file. Any model — RBAC, ABAC, RBAC with domains, ACL — is expressed via a four-part PERM (Policy, Effect, Request, Matchers) model.

# Casbin RBAC with domains
[request_definition]
r = sub, dom, obj, act

[policy_definition]
p = sub, dom, obj, act

[role_definition]
g = _, _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act

# policy.csv example
# p, admin, tenant1, data1, read
# p, admin, tenant1, data1, write
# g, alice, admin, tenant1

Casbin's strength is in-process embedding — no separate server required. Its weakness is that with such an open-ended model, anything Zanzibar-grade (global consistency, snapshot reads) must be implemented yourself.

11. Oso — authorization embedded with Polar

Oso is an authorization startup from 2020 that authored its own policy language, Polar (Prolog-inspired). It pivoted to Oso Cloud as the primary SaaS in 2024 while keeping the open-source embedded library. The strength: natural integration with host-language objects (Python, Node, Rust).

A single Polar line reads almost like prose: allow(actor, "read", resource) if actor in resource.viewers;.

Oso Cloud also functions as a Zanzibar-style central permission store via a data sync model (the application DB streams changes in as facts). License: Apache 2.0 plus commercial cloud.

12. Ory Keto / Warrant / Aserto / Topaz — the supporting cast

• Ory Keto: the authorization component of the Ory ecosystem (Hydra OAuth2, Kratos Identity). Originally an ACL model; rewritten on the Zanzibar model in 2021. Implemented in Go.
• Warrant: YC W22 alum. Faithful Zanzibar implementation, acquired by Okta in 2023 (unified with OpenFGA).
• Aserto: a hybrid of a Zanzibar directory and OPA Rego. Self-hosted plus SaaS.
• Topaz: Aserto's open-source core. Deployed as a sidecar, combining a directory with policy.

Topaz is particularly interesting because it explicitly proposes the hybrid model: "use Zanzibar for the relationship graph (who is a member of what) and Rego for the policy decision (is this action allowed)."

13. OPA (Open Policy Agent) — a general-purpose policy engine

OPA started in 2016 and graduated CNCF as a general-purpose policy engine, not strictly an authorization engine. It shows up everywhere — Kubernetes admission control, Envoy/Istio policies, Terraform policies, CI/CD gates. Its policy language is Rego, inspired by Datalog.

# Rego policy: document access
package documents.authz

import future.keywords.if
import future.keywords.in

default allow := false

allow if {
  input.action == "view"
  input.user.id == input.resource.owner
}

allow if {
  input.action == "view"
  input.user.id in input.resource.viewers
}

allow if {
  input.action in {"view", "edit"}
  input.user.role == "admin"
}

allow if {
  input.action == "view"
  group := input.resource.groups[_]
  group in input.user.groups
}

OPA's strengths are expressiveness and ecosystem. Weaknesses: relationship-graph storage is not first-class (you must sync data separately), and Rego has a steep learning curve.

14. The Check API — the heart of FGA

Every FGA system has the same single core API: Check. It returns boolean for "can subject S perform action A on resource R."

// SpiceDB Go SDK
client := authzed.NewClient("localhost:50051", grpcOpts...)

resp, err := client.CheckPermission(ctx, &v1.CheckPermissionRequest{
  Resource: &v1.ObjectReference{
    ObjectType: "document",
    ObjectId:   "readme",
  },
  Permission: "view",
  Subject: &v1.SubjectReference{
    Object: &v1.ObjectReference{
      ObjectType: "user",
      ObjectId:   "alice",
    },
  },
  Consistency: &v1.Consistency{
    Requirement: &v1.Consistency_MinimizeLatency{MinimizeLatency: true},
  },
})

if resp.Permissionship == v1.CheckPermissionResponse_PERMISSIONSHIP_HAS_PERMISSION {
  // allowed
}

Key parameters:

• Consistency: pick MinimizeLatency (cache first), AtLeastAsFresh (must be at least as fresh as a Zookie), or FullyConsistent (always current, expensive).
• Resource / Permission / Subject: the standard (object, relation, user) tuple.

p99 < 10ms is the shared SLO target for SpiceDB and OpenFGA.

15. ListObjects vs ListRelations — the expensive queries

Check returns a single boolean, but real UIs need more.

• ListObjects(user, permission): "all documents alice can view" — required for file-list UIs.
• ListRelations(resource, permission): "all users who can view this document" — required for share dialogs.
• Lookup(user, resource): "all permissions alice has on this document" — required for debugging.

ListObjects is reverse graph traversal, so it is far more expensive than Check. SpiceDB exposes a separate LookupResources API; OpenFGA exposes ListObjects. Both require pagination as result counts grow.

// OpenFGA ListObjects response
{
  "objects": [
    "document:readme",
    "document:design-doc",
    "document:budget-2026"
  ]
}

The most common anti-pattern when wiring this into UI pagination: fetch everything via ListObjects and paginate client-side — explodes once permission counts grow. The right answer is filtered list combined with DB pagination (e.g. SpiceDB's cursor-based pagination).

16. Schema design — namespaces, relations, conditions

Common traps in Zanzibar-style schema design.

1. Do not over-split resource types. Prefer a single "asset" with a type attribute over "Document, Image, Video, Audio, PDF" — keeps ListObjects cost down.
2. Make groups first-class. Zanzibar's advantage is group-membership traversal. If you do not give groups their own namespace, you forfeit that advantage.
3. Conditional relations subsume ABAC. SpiceDB's Caveats and OpenFGA's Conditions express ABAC-style constraints like "only on Mondays, only from a corporate IP."
4. Separate permission from relation. relation viewer: user is data (who is a viewer); permission view = viewer + owner is computed (view is viewer or owner). Grant relations, not permissions.

17. Multi-tenant isolation patterns

The most common SaaS requirement. How do you isolate multiple tenants on the same FGA backend?

Three patterns:

1. Tenant prefix: prepend the tenant to the object_id, e.g. document:tenant1/readme. Simple but weak on cross-tenant queries.
2. Tenant namespace: duplicate the schema per tenant. Same schema cloned, with operational overhead.
3. Tenant as root object: define definition tenant { relation member: user } and have every resource carry relation tenant: tenant. Permission computation always passes through tenant->member. The recommended pattern.

Permify explicitly supports multi-tenancy as first-class with /v1/tenants/{tenantId}/... APIs. SpiceDB and OpenFGA express it via schema.

18. Postgres RLS — fallback or complement

Postgres Row-Level Security enforces authorization at the DB layer. Before adopting an FGA, if your requirement is just simple multi-tenancy, RLS alone is sufficient.

-- Postgres RLS: multi-tenant isolation
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

CREATE POLICY user_owned ON documents
  USING (owner_id = current_setting('app.current_user')::uuid);

-- In the application
SET app.current_tenant = '550e8400-e29b-41d4-a716-446655440000';
SET app.current_user  = '7a8e9c00-1234-5678-9abc-def012345678';

SELECT * FROM documents;  -- automatically filtered

RLS's strength: even if the application has a bug, the DB blocks the read. Weakness: very weak on deep relationship graphs (group of group of folder). So the 2026 recommendation is a two-layer defense — FGA as the top-level decision, RLS as the backstop. This is also why Supabase markets RLS as a core feature.

19. Performance — latency vs consistency trade-offs

Three axes that determine FGA performance.

1. Graph depth: the deeper the path from resource to user, the more expensive Check is. Zanzibar usually caps it at five hops.
2. Graph fan-out: a single group with a million members is expensive without a pre-index like Leopard.
3. Consistency requirement: the choice between MinimizeLatency (cache OK) and FullyConsistent (always current) dominates p99.

Cerbos and OPA are faster on Check itself but cannot do graph queries like ListObjects. Always remember that.

20. Edge authorization — Cloudflare, Fastly + OPA

A pattern rising since 2025: make the authorization decision at the edge. Cloudflare Workers, Fastly Compute@Edge, AWS Lambda@Edge run an OPA WASM bundle or a SpiceDB cache to deny requests before they reach origin.

Pros: p50 < 10ms authorization on a globally distributed SaaS, reduced origin load, DDoS-grade denial. Cons: policy-change propagation lag, cache consistency across edge nodes.

OPA WASM compiles Rego policies to a WASM module embeddable in any runtime. SpiceDB streams permission-graph changes to external caches via its Materialize API.

21. Zanzibar-style vs OPA-style — how to choose

The most-asked question. A simple decision tree.

1. Is your data a relationship graph? If you have 3+ deep chains like "this folder is a child of that folder, which is a child of..." → Zanzibar-style (SpiceDB, OpenFGA, Permify).
2. Is your data flat but the policy is complex? If you have many conditions like "admin only on weekdays from 9-6 on a corporate IP, contractors only after NDA signed" → OPA / Cedar / Cerbos.
3. Both? → A hybrid like Topaz/Aserto, or SpiceDB combined with OPA.
4. Embedded? → Casbin / Oso (in-process libraries).
5. AWS-only? → Amazon Verified Permissions (managed Cedar).

22. SaaS vs self-hosted

Korean financial sector, public sector, and Japanese enterprises where data sovereignty matters effectively force self-hosting. Global SaaS startups tend to adopt Authzed Cloud or Auth0 FGA quickly.

23. Migrating from RBAC to ReBAC

A four-phase pattern for moving an existing RBAC system (role table plus permission matrix) over to ReBAC.

1. Dual write: on every grant, write to both the RBAC table and the FGA. Reads still go to RBAC.
2. Shadow compare: evaluate every RBAC decision against FGA too, and track match rate as a metric. Move on once it stays above 95%.
3. Read flip: feature-flag some traffic to FGA decisions. Roll out gradually.
4. Cleanup: remove the RBAC table or keep it only as a backup.

Both the SpiceDB team's blog and the OpenFGA docs recommend this exact pattern.

24. Case studies — Naver, Kakao, AWS Tokyo, Cybozu

Naver Cloud IAM (2024): Naver ran its own RBAC plus ABAC hybrid until adopting a self-hosted SpiceDB cluster specifically for content permissions (blog, cafe, smartstore sharing). Multi-region consistency requirements meant they did not adopt Authzed Cloud.

Kakao KOLON authorization (2025): as the permission model for Kakao Works and Kakao Talk channels grew explosively, Kakao internally released a Zanzibar clone (codename KOLON). At if(kakao) 2026 they announced it is under consideration for open-sourcing.

AWS Tokyo IAM (2025): AWS launched Amazon Verified Permissions in the Tokyo region for Japanese financial-sector customers. Cedar policies plus automatic metadata logging meet Japan's 2025 APPI amendment requirement for five-year access-log retention.

Cybozu kintone (2024): kintone, a flagship Japanese SaaS, restructured its permission model on OpenFGA. The legacy PHP-based engine had hit its ceiling as the permission graph deepened. The case was presented at KubeCon Japan.

Beyond these, KakaoBank's internal permission system, LINE's message ACLs, and Rakuten's mobile in-app permissions have been reported as ReBAC transition cases.

25. Looking ahead — what comes next in 2026

• Agent authorization: when an LLM agent acts on behalf of a user, you need new relationship patterns for "what permissions has this agent been delegated." Cedar and SpiceDB both saw a surge in delegation keyword usage starting in late 2025.
• Mainstreaming policy verification: Cedar's verifiability is spreading to other policy languages. OPA has a formal verification track in progress.
• GraphQL/REST integration standards: efforts to inline authorization metadata into API schemas via OpenAPI/GraphQL extensions. OpenFGA published a GraphQL Authorization Extension draft.
• On-prem GenAI authorization: internal RAG systems evaluating "is this document allowed in this user's search results" on every search. The combination of SpiceDB and a vector DB is showing up as a reference implementation.
• Authorization-data standardization: rumors of IETF-level work on a portable format for authorization data across FGA systems.

26. References

• Google Zanzibar paper (USENIX ATC '19): https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/
• Zanzibar on arXiv: https://arxiv.org/abs/1906.10247
• SpiceDB / AuthZed: https://authzed.com/
• SpiceDB docs: https://authzed.com/docs/spicedb/getting-started/discovering-spicedb
• OpenFGA: https://openfga.dev/
• OpenFGA modeling guide: https://openfga.dev/docs/modeling/getting-started
• Permify: https://permify.co/
• Permify docs: https://docs.permify.co/
• Cerbos: https://cerbos.dev/
• Cerbos policy docs: https://docs.cerbos.dev/cerbos/latest/policies/
• AWS Cedar: https://www.cedarpolicy.com/
• Amazon Verified Permissions: https://aws.amazon.com/verified-permissions/
• Casbin: https://casbin.org/
• Oso: https://www.osohq.com/
• Ory Keto: https://www.ory.sh/keto/
• Aserto: https://www.aserto.com/
• Topaz: https://www.topaz.sh/
• Open Policy Agent (OPA): https://www.openpolicyagent.org/
• OPA Rego language: https://www.openpolicyagent.org/docs/latest/policy-language/
• Postgres Row-Level Security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• CNCF OpenFGA page: https://www.cncf.io/projects/openfga/
• AWS Cedar Language Specification: https://docs.cedarpolicy.com/policies/syntax-grammar.html