Enforcer
Auth0 FGA is a hosted authorisation service. Its own documentation states that "Auth0 FGA is based on OpenFGA, an open-source project owned by the Cloud Native Computing Foundation for which Auth0/Okta is a core maintainer". You write relationship tuples into a store, define an authorisation model, and call Check, BatchCheck, ListObjects or ListUsers. It is relationship-based access control in the Google Zanzibar style, and it is an authorisation service only. Authentication, tenants and user records live in a separate system. The reasons teams go looking elsewhere are mostly commercial and operational rather than a complaint about the model.
ListObjects payload returned as HTTP 200 with no warning header. Both were still open when we checked on 15 September 2026.but not, with the qualifier that your authorisation model can still contain any of these patterns but they cannot appear on the indexable path.Stay on Auth0 FGA if your authorisation problem is genuinely a relationship graph: nested folders, shared documents, org and team hierarchies, and you need to ask which objects a user can see across large result sets. That is the problem Zanzibar was designed for. Stay if the surrounding tooling matters, because the OpenFGA repository lists SDKs for Java, Node.js, Go, Python and .NET, a CLI, a Terraform provider and a playground, and names Auth0, Grafana Labs, Canonical and Docker among its adopters. Stay if you need an authorisation decision log without building one: the FGA Logging API announcement states that "Logs are captured for all public Auth0 FGA APIs, including relationship tuple changes, access checks, and authorization model updates", that a Check query returns the allowed: true or allowed: false result, and that "The FGA Logging API is now available for all paid-tier customers." That last condition matters: it is not part of the free trial. Stay if you already run Auth0 for identity, because the two products are sold and supported together. Stay if CNCF governance matters to procurement, or if you want the option to self-host the same core engine under Apache-2.0 and move to the hosted service later. Note that the hosted product adds capabilities the open-source engine does not have, including the Logging API and the Permissions Index, so the portability you get applies to your authorisation model rather than to the full feature set.
| Option | Model | Strength | Trade-off |
|---|---|---|---|
| OpenFGA, self-hosted | Zanzibar-style relationship tuples, Apache-2.0, CNCF project | The same core engine Auth0 FGA is built on, free and self-hosted, with HTTP and gRPC APIs. It removes the enterprise-contract requirement and the trial caps entirely. The repository is Apache-2.0 and had 5,773 GitHub stars on 15 September 2026. | You operate it. The README marks the memory storage adapter as "for development only", lists supported storage as PostgreSQL 14+, MySQL 8 and SQLite in beta, and notes that the MySQL storage engine has stricter length limits on tuple properties than other backends. The ListObjects deadline and conditional-tuple issues above are the same code, so self-hosting does not fix them, and you do not get the hosted Logging API or Permissions Index. |
| SpiceDB, by AuthZed | Zanzibar-style relationship tuples with caveats, Apache-2.0 | A Zanzibar implementation with 7,054 GitHub stars on 15 September 2026. The README describes consistency configured per request, caveated relationships that mix ABAC and ReBAC, and reverse indexes for the two questions that matter, what a subject can do and who can access a resource. Its Who uses SpiceDB? section highlights IBM's AI Data & Model Factory Platform, Red Hat's Insights Platform and Gitpod. | Same architectural burden as FGA. The README states: "SpiceDB is focused purely on authorization and is designed to be fully agnostic to authentication solutions/identity providers." It stores relationships, not your data, so your application owns the dual write into the permission store and the job of keeping it in step. AuthZed's pricing page lists four plans: open source and free, a self-service Cloud tier billed on usage, Self-Hosted on request a quote, and Dedicated Cloud on contact sales. |
| Cerbos | Stateless policy decision point, YAML policies in git, Apache-2.0 | Cerbos is a stateless policy decision point, with 4,587 GitHub stars on 15 September 2026. Policies are YAML files stored on disk, in cloud object stores, in git repos or in supported databases, so they go through the same pull request review as your code. It runs in Kubernetes as a service or a sidecar, directly as a systemd service, or as an AWS Lambda function. PlanResources answers which resources of a given kind a principal can access and returns a query plan, with adapters that turn that plan into a database query. | It holds no relationship data. Every call carries the principal and resource attributes, so your application still fetches and assembles that context on the hot path. Deep nested hierarchies are awkward to express compared with a relationship graph. |
| Ory Keto | Zanzibar-style relationship tuples with the Ory Permission Language, Apache-2.0 | Apache-2.0 with 5,396 GitHub stars on 15 September 2026, with a managed option as Ory Permissions on Ory Network, and it sits alongside Ory Kratos if you want identity from the same vendor. The README lists sub-10ms permission checks and horizontal scaling to billions of relationships among its focus areas. | Smaller ecosystem than OpenFGA or SpiceDB, and the identity pairing means adopting a second Ory component rather than getting identity in the same service. The performance figures above are the project's own README claims, not an independent benchmark. |
| Topaz, by Aserto | OPA as the decision engine plus a built-in Zanzibar-inspired directory, Apache-2.0 | Topaz uses the Open Policy Agent as its decision engine and adds a built-in directory inspired by the Google Zanzibar data model. Its README states that authorisation policies can use user attributes, group membership, application resources and the relationships between them, and that all data used for authorisation is modelled and stored locally in an embedded database, so a decision does not require a round trip to fetch context. | The smallest community of the open-source options on this page, at 1,361 GitHub stars on 15 September 2026, against 4,587 for Cerbos, 5,396 for Keto, 5,773 for OpenFGA, 5,951 for Permify and 7,054 for SpiceDB. Running OPA well means owning Rego, which is a real learning cost for a team that has not used it. |
| Permify | Zanzibar-style relationship tuples, AGPL-3.0, part of FusionAuth | A Zanzibar-style engine with its own schema language, at 5,951 GitHub stars on 15 September 2026. FusionAuth announced its acquisition of Permify on 20 November 2025, putting authentication and fine-grained authorisation under one owner. | The repository is AGPL-3.0, not Apache-2.0, which some legal teams will not clear for a service sitting in the request path. Check that with counsel before you build on it. |
Where Enforcer genuinely differs: identity and authorisation are one service, so the policy is handed an already-resolved caller, and the decision returns a reason and the policy id. Auth0 FGA is an authorisation service, and the identity half is a separate product and a separate integration. SpiceDB's README says the same of itself, that it is agnostic to authentication solutions and identity providers.
Where Enforcer is worse, and these are not small.
List filtering only over Enforcer’s own resource types. The engine compiles the same policy into a SQL WHERE clause by partial evaluation, exposed over gRPC as CompileFilter, but only for the eleven types registered in Enforcer’s own process (account, group, tenant, ticket, wallet and six more). There is no REST endpoint for it and no way to register your own tables, so you cannot use it to filter your application’s data. Enforcer cannot answer "give me every resource this user can read" over your tables. Every option on this page can, whether through ListObjects, a reverse index or PlanResources. If your product is a document store or a shared workspace, that gap will decide the evaluation against you.
No decision log out of the box. Auth0 FGA ships a Logging API that records Check calls and their allowed result for paid-tier customers. Enforcer has no equivalent. GET /audit-events is the identity and admin trail, covering logins, API keys, roles, tenants and terms, and it never records authorisation decisions. You log the returned reason and policy_id yourself.
The resource is an assertion. On POST /authz/check the resource is described by the caller and never looked up, so owner_id is an assertion your application must resolve server side. Get that wrong and the built-in policy will authorise a forged owner.
No shadow or preview evaluation. An inactive policy is stored and simply not evaluated. There is no way to run a candidate policy against live traffic and compare before you cut over.
The built-in baseline is wider than default-deny. Before any rule exists, a built-in baseline already allows any action other than manage on a row the caller owns. It also allows group and group type reads across the caller's tenant, and the caller's own audit events and global policies. A cross-tenant admin is allowed everything. Know the full shape of that default before you rely on it.
Named policies replace, they do not intersect. A named policy replaces the built-in decision rather than intersecting with it, and contexts only reaches a named policy. Custom policies are Rego in package enforcer.custom, compiled at write time, capped at 64KB with a 100ms evaluation budget, and creating one requires tenant admin.
We are small and new. No independent reviews, no large community, no CNCF governance, no published adopter list. OpenFGA is a CNCF project with a five-language SDK set and named adopters. If procurement weighs maturity, Enforcer loses that column.
Sources checked 15 September 2026: docs.fga.dev/fga · docs.fga.dev/subscription-plans · docs.fga.dev/permissions-index/fga-permissions-i · www.okta.com/pricing/auth0/ · auth0.com/blog/auth0-fga-logging-api-a-complete- · openfga.dev/docs/interacting/search-with-permiss · github.com/openfga/openfga · raw.githubusercontent.com/openfga/openfga/main/R · github.com/openfga/openfga/issues/1961 · github.com/openfga/openfga/issues/2151 · github.com/openfga/openfga/issues/3276 · github.com/authzed/spicedb