Fine-Grained Authorization (FGA): A 2026 Implementation Guide

Key takeaways

• FGA is permissions at the resource-instance level, 'Alice can edit Project X' rather than 'Alice is admin.'
• Most modern FGA implementations are Zanzibar-derived and built around relation tuples + a schema language.
• The major 2026 implementations: OpenFGA, SpiceDB, Permify, Ory Keto, plus CIAM-bundled options Auth0 FGA, WorkOS FGA, Authress.
• FGA pairs with RBAC: RBAC for coarse policy, FGA for per-resource decisions. Most B2B SaaS run both.
• Performance at billions of objects is solved; the harder problem is schema design and integration latency.

What FGA actually solves

The decision to adopt FGA usually surfaces around the moment teams realize they're creating roles like editor-of-project-X to express resource-scoped permissions. That's role explosion; the model has broken; FGA is the answer.

The Zanzibar model

The data primitive is the relation tuple: <object>#<relation>@<subject>.

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

Read aloud: "Alice is editor of project:acme-launch." "Engineering team is viewer of project:acme-launch." "Bob is member of engineering team." "Document roadmap-v3 has parent project:acme-launch."

Authorization checks traverse the graph. "Can Bob edit document:roadmap-v3?" → walk: roadmap-v3 has parent acme-launch → who has edit on acme-launch? → Alice directly, engineering team's members through inheritance → Bob is in engineering → does engineering inherit edit from viewer? Schema decides.

The schema language defines which permissions imply which others. A typical pattern: editor implies viewer (an editor can also view); document inherits permissions from parent (project's editor can edit the document). The schema is per-deployment; teams customize it for their object model.

Performance characteristics

Production FGA implementations target sub-10ms checks at billions-of-tuples scale. The architecture pattern:

• Storage layer. Relation tuples in a standard database (Postgres, Spanner, FoundationDB).
• Cache layer. Recent decisions cached at the FGA service for short TTLs.
• Consistency tokens (zookies). A token issued at write time the relying party presents at read time, ensuring read-after-write consistency without globally serializing.

The result: FGA decisions are fast enough to invoke per request, even on hot paths. Application-layer caching adds another order of magnitude where stale-by-seconds is acceptable.

Production implementations

Five major Zanzibar-derived implementations are production-ready in 2026:

• OpenFGA, CNCF Sandbox project, originated at Auth0 / Okta, broadly vendor-neutral. The default choice for greenfield deployments without specific CIAM coupling.
• SpiceDB / Authzed, commercial Zanzibar implementation, also available as OSS. Strong tooling, professional support tier, used by several large SaaS deployments.
• Permify, OSS Zanzibar with growing adoption, lightweight operational profile.
• Ory Keto, bundled with the Ory stack; cleanest fit for teams already running Ory components.
• Casdoor, integrates Casbin (the long-standing authorization library by the same maintainer) for FGA-adjacent functionality.

CIAM-bundled FGA:

• Auth0 FGA, managed, tightly integrated with Auth0 CIAM; the path-of-least-resistance for Auth0 customers.
• WorkOS FGA, managed, bundled with WorkOS B2B SaaS auth; included at standard tier.
• Authress, the only full-platform CIAM in this index built around FGA as the design center.

When FGA isn't the answer

Three scenarios where simpler models win:

• Small role count. Five roles, no per-resource variation, RBAC is fine; FGA is overkill.
• Pure attribute-based policy. Time-of-day, geographic restrictions, classification levels, ABAC via OPA / Rego is more idiomatic than FGA's relation model.
• Greenfield with no clear authz needs yet. Don't pre-optimize. Start with RBAC; adopt FGA when the role explosion becomes the binding constraint.

How to compose RBAC and FGA

The 2026 default for B2B SaaS:

• RBAC for coarse policy at the Organization level. "Alice is admin of Acme Corp" controls access to admin-only operations.
• FGA for resource permissions within the Organization. "Alice can edit Project X within Acme Corp", the role is admin (RBAC), the resource permission is edit-on-X (FGA).

Most CIAM that ship native FGA integrate the two: the user's RBAC role provides default FGA tuples, the application layer adds resource-specific tuples on the fly. Auth0 FGA, WorkOS FGA, and Authress all do this.

Vendor support snapshot

For new authorization deployments needing FGA in 2026:

• Greenfield without CIAM coupling: OpenFGA or SpiceDB. Both production-ready, both Zanzibar-derived, both have growing communities.
• Existing Auth0 customer: Auth0 FGA. Tight integration, managed, fits the path of least resistance.
• Existing WorkOS B2B SaaS customer: WorkOS FGA. Bundled, no separate vendor.
• CIAM choice contingent on FGA depth: Authress. Built around FGA as the design center; deeper than CIAM-with-FGA-bundle alternatives.
• Self-hosted with Ory stack: Ory Keto. Native fit.