OpenFGA
Last verified 2026-08-21 · Reviewed by guptadeepak
Editorial verdict
OpenFGA is the default open-source answer to fine-grained authorization in 2026, and it is deliberately not a CIAM. It implements the Zanzibar relationship model under Apache 2.0 with CNCF incubating governance, which makes it the safest long-horizon bet for teams who want the permission model itself to outlive any vendor relationship. Pair it with whichever CIAM handles your logins. The cost is not licence fees, it is the modeling work and the operational reality of putting a stateful service in your request path, and teams that skip the modeling phase are the ones who regret the choice.
Last verified by @guptadeepak on 2026-08-21.
At a glance
- Best for
- B2B SaaS with per-resource, nested, or shared-object permissions that RBAC cannot express
- Pricing
- free-open-source
- Free tier
- Unlimited
- Deployment
- self-hosted
- SOC 2 Type II
- No
- Passkeys
- No
- Self-host
- Yes
- Open source
- Yes
Funding & business
- Funding model
- Open-source / foundation
- Total raised
- None
- Latest round
- None disclosed
- Years in business
- 4 yrs
- Profitable
- Not disclosed
Built by the FGA team at Auth0 (Okta) and donated to the Cloud Native Computing Foundation in September 2022. Accepted as a CNCF incubating project in October 2025. No commercial entity owns the project; Auth0 FGA and Okta FGA are the managed products built on it.
Funding data from primary source. See also the CIAM investor landscape.
Strengths
- The reference open-source implementation of Google's Zanzibar model, with CNCF incubating status and maintainers from Okta and Grafana rather than a single vendor.
- Relationship-based authorization that expresses nested, per-resource permissions RBAC cannot, with RBAC and ABAC (via CEL conditions and contextual tuples) as subsets of the same model.
- Apache 2.0 with no open-core split; the feature you need is not gated behind a commercial tier.
- Stores only relationship tuples over opaque object identifiers, so the authorization service holds no profile data and stays outside most PII blast radii.
- Official SDKs for Go, Java, Node, Python, and .NET, plus a CLI and a local single-binary mode that makes it genuinely testable in CI.
Limitations
- Not a CIAM product. No authentication, no user store, no registration, no MFA. It answers one question: is this subject allowed to do this on that object.
- Compliance certifications do not apply to a self-hosted project. SOC 2, ISO 27001, and HIPAA are attributes of your deployment, and the audit burden moves to you.
- Modeling is the hard part. Teams routinely underestimate the design work of translating an existing permission scheme into a Zanzibar authorization model.
- It sits in the request path. Latency, caching, and consistency (the Zanzibar Zookie problem) become your engineering problem at scale.
- No managed hosting from the project itself. The managed path is Auth0 FGA or Okta FGA, which reintroduces vendor pricing.
Capability matrix
Every vendor scored on the same axes. See the methodology for criteria.
| Password authentication | No |
|---|---|
| Social login | No |
| Magic links | No |
| SMS OTP | No |
| Email OTP | No |
| TOTP (authenticator app) | No |
| Push MFA | No |
| WebAuthn / passkeys | No |
| Biometric | No |
| Hardware security keys | No |
| SAML SSO | No |
| OIDC SSO | No |
| OAuth 2.0 SSO | No |
| Enterprise federation | No |
| Passwordless-only flows | No |
| Adaptive MFA | No |
| Step-up auth | No |
| RBAC | Yes |
|---|---|
| ABAC | Yes |
| ReBAC | Yes |
| FGA engine | Yes |
| API authorization | Yes |
| Fine-grained permissions | Yes |
| Self-service registration | No |
|---|---|
| Progressive profiling | No |
| Self-service account | No |
| Bulk user import | No |
| Admin user search | No |
| Custom user metadata | No |
| Organizations / tenants | No |
| Multi-tenancy | Partial |
| SCIM provisioning | No |
| REST API | Yes |
|---|---|
| GraphQL API | No |
| SDKs | Go, Java, JavaScript/Node, Python, .NET |
| CLI | Yes |
| Terraform provider | No |
| Local emulator | Yes |
| Extension model | Conditions (CEL expressions) for ABAC, plus pluggable datastore backends (Postgres, MySQL, SQLite, in-memory) |
| Bot detection | No |
|---|---|
| Breached password detection | No |
| Brute-force protection | No |
| Anomaly detection | No |
| Log streams | Partial |
| Audit logs | Partial |
| GDPR data export | No |
| PII minimization | Yes |
| Post-quantum roadmap | No |
| MCP support | No |
|---|---|
| OAuth 2.1 | No |
| Dynamic client registration | No |
| Agent vs human token separation | No |
| Web Bot Auth | No |
| SOC 2 Type II | No |
|---|---|
| ISO 27001 | No |
| ISO 27018 | No |
| HIPAA | No |
| PCI DSS | No |
| GDPR | No |
| CCPA | No |
| FedRAMP | No |
| EU data residency | Yes |
| Consent management | No |
|---|---|
| Preference center | No |
| Purpose-specific consent | No |
| Integrates with CMPs | n/a |
| Multi-region deployment | Partial |
|---|---|
| Data residency control | Yes |
| Proven at high scale (1M+ MAU) | Yes |
| Password-hash import | No |
|---|---|
| Lazy / just-in-time migration | No |
| Account linking & dedup | No |
| Custom domains per brand | No |
| Per-brand theming of all flows | No |
| Per-brand consent partitioning | No |
| Deletion webhooks / cascade | No |
| Event streaming / webhooks | Partial |
| Documented rate limits | No |
Developer experience & lock-in
Editorial 1–5 scores and migration effort, scored on the same axes for every vendor. See the methodology for how these are graded.
Developer experience
- Community
- Medium
- GitHub stars
- 5,600
Migration & lock-in
Moderate lock-inEffort to adopt this platform
Effort to leave later (your exit cost)
Open source and self-hostable, so you keep full data and deployment portability regardless of the score above.
Enterprise readiness
Gaps remain · 24/100A computed read of how ready this vendor is to sell into the enterprise, derived from the capability matrix. See the enterprise-ready pillars.
- 0
Enterprise SSO
- 0
Directory sync (SCIM)
- 20
Organizations & tenancy
Multi-tenancy (partial)
- 100
RBAC & custom roles
RBAC · ABAC / ReBAC / FGA · Fine-grained permissions
- 50
Audit logs & streaming
Audit logs (partial) · Log streaming (partial)
- 0
Compliance certifications
- 0
Security posture
Scored from our capability review; confirm the exact plan tier and SCIM scope with the vendor before you commit.
Pricing
| 10,000 MAU | Quote required |
|---|---|
| 100,000 MAU | Quote required |
| 500,000 MAU | Quote required |
| 1,000,000 MAU | Quote required |
- Software is Apache 2.0 and free; the cost is the database, compute, and on-call rotation you run it on
- Authorization sits in the request path, so the real budget line is latency engineering and cache design, not licence fees
- Managed alternative is Auth0 FGA / Okta FGA, priced separately and not covered by this profile
Estimates use the standard assumptions in our methodology. Always confirm with the vendor.
Best for
- B2B SaaS with per-resource, nested, or shared-object permissions that RBAC cannot express
- Teams already running a CIAM for authentication that need authorization as a separate service
- Platform teams that want authorization as infrastructure they control, on any cloud
- Organizations avoiding vendor lock-in on the permission model itself
Not for
- Teams looking for a CIAM platform; OpenFGA replaces no part of authentication
- Small teams without the appetite to run a stateful service in the request path
- Buyers who need a vendor's SOC 2 report to cover their authorization layer
Solves for
Enterprise pain points this vendor covers on the mapped capabilities. See all pain points.
FAQ
- Is OpenFGA a CIAM or an alternative to Auth0?
- Neither. OpenFGA does authorization only: given a subject, a relation, and an object, it returns allowed or not. It has no login flows, no user store, no MFA, and no registration. You still need a CIAM alongside it. Auth0 is a comparison point only for Auth0 FGA, the managed service Okta built on top of OpenFGA.
- What is the difference between OpenFGA and Auth0 FGA?
- Same engine lineage, different operating model. OpenFGA is the Apache 2.0 project you self-host and operate. Auth0 FGA (marketed as Okta FGA) is the managed, commercially supported service built from it. Choose OpenFGA when you want control and no per-evaluation pricing, and the managed product when you would rather not run a stateful service yourself.
- When is OpenFGA overkill compared to plain RBAC?
- If your permission questions are answered by a role column on the user record, RBAC is enough and OpenFGA adds a service for no gain. The signal to move is nesting and sharing: documents inside folders inside workspaces, permissions inherited down a tree, per-object grants to individuals, or cross-tenant sharing. Those are the cases where RBAC turns into a pile of special-case code.
- How does OpenFGA compare to Authress, Authzed, or Permify?
- All four implement Zanzibar-style relationship-based authorization. OpenFGA is the CNCF-governed, self-hosted reference implementation. Authzed (SpiceDB) and Permify are the other major open implementations, each with their own managed offering. Authress differs in kind: it wraps authorization together with authentication in a single commercial product, so it competes for the whole slot rather than just the authorization layer.
Sources
- OpenFGA Documentation: What is Fine-Grained Authorizationaccessed 2026-08-21
- OpenFGA Becomes a CNCF Incubating Projectaccessed 2026-08-21
- Announcing OpenFGA, Auth0's Open Source Fine Grained Authorization Systemaccessed 2026-08-21
- openfga/openfga on GitHubaccessed 2026-08-21
Where to next
What OpenFGA is
OpenFGA is an authorization engine, not an identity platform. It stores relationship tuples ("user:alice is an editor of document:roadmap") and answers permission checks against an authorization model you define. The design comes from Google's Zanzibar paper, the system behind permissions in Drive and YouTube. Auth0's FGA team built it, open-sourced it in 2022, and donated it to the CNCF, where it reached incubating status in October 2025.
The practical consequence is that OpenFGA occupies one slot in your stack and leaves the others empty. Authentication, user profiles, MFA, and registration all stay wherever they are today.
Where OpenFGA wins
Expressiveness first. Relationship-based access control handles the permission shapes that break RBAC: inheritance down a folder tree, per-object sharing, group-of-group membership, and conditional access evaluated against request context. RBAC and ABAC are both expressible in the same model rather than bolted on beside it.
Governance second. CNCF ownership with maintainers from more than one company means the permission model is not a lock-in surface. If you later want the managed version, Auth0 FGA speaks the same model; if you want out, the tuples and the model are yours in a documented format.
Third, the privacy posture is unusually good. The authorization store holds opaque identifiers and relationships, not names, emails, or profile attributes, which keeps it out of the blast radius that CIAM databases sit in.
Where OpenFGA hurts
The modeling work is real and front-loaded. Translating an existing permission scheme into type definitions and relations is a design exercise, and teams that treat it as a migration script produce models they rewrite six months later.
Operating it is your problem. It is a stateful service on the hot path of every request, so caching, replication, and the Zanzibar consistency tradeoff all land on your team. There is no project-run managed tier.
Compliance does not transfer. A vendor's SOC 2 report covers the vendor. Self-hosting OpenFGA means your own controls cover the authorization layer, which is fine for most teams and a genuine obstacle for those who buy on certification checklists.
How OpenFGA compares
Within this index, Authress is the closest relative and the sharpest contrast: it builds authentication and Zanzibar-style authorization into one commercial product, where OpenFGA does authorization only and expects a CIAM beside it. For CIAM platforms that ship their own FGA engine rather than pairing with an external one, see Auth0 and WorkOS.
For the model itself rather than the vendor choice, read Zanzibar explained for the paper OpenFGA implements, then fine-grained authorization (FGA) and API authorization patterns. The distinction between RBAC, ABAC, ReBAC, and PBAC is covered in RBAC vs ABAC vs ReBAC vs PBAC.
Editorial changelog (1 entry)
Profile added. Capabilities, governance status, and pricing model verified against OpenFGA docs, the CNCF incubation announcement, and the project repository.