Which open-source alternative to Auth0 Fine-Grained Authorization fits your team?
If your team pays for Auth0 FGA or needs relationship-based permission checks that you cannot host in your own environment, OpenFGA is the closest open-source match. It is the CNCF incubating project that Auth0 FGA runs on, its README states Auth0 FGA has used it in production since December 2021, and it is licensed under Apache-2.0. Ory Keto is the alternative to weigh alongside it, because it is also based on Google's Zanzibar approach and supports ACL and RBAC models, but it is a different project with its own store, API and operational model, so it needs a separate evaluation against your schema. The identity provider stays separate from this decision. Login (who the user is, how they sign in, which tokens they receive) and authorization (what a given user may do to a given object) are replaced as two decisions. Your current or chosen identity provider, such as Keycloak, ZITADEL or Ory Kratos, continues to issue tokens, and the permission service answers check calls from your applications. Plan both migrations in the same project plan, but test them separately so a problem in one does not hide a problem in the other. Before choosing, confirm three things. First, the authorization model: export your current FGA type definitions and sample tuples, then check that each relationship and computed permission can be expressed in the target's modeling language. Second, the storage database: OpenFGA supports PostgreSQL 14 or later and MySQL 8, and SQLite is in beta, so decide which database your platform team already backs up, monitors and patches. Third, who runs the service: ask whether your own staff, a managed provider or an implementation partner will operate upgrades, backups and on-call duty. Ask your vendors to put those responsibilities in writing.
How each Auth0 FGA capability maps to open-source options
This table maps the main Auth0 FGA capabilities to OpenFGA and Ory Keto, and marks where coverage depends on the API version or on something you must verify in a test environment. Use it as a checklist: any row marked for verification should become a proof-of-concept test before you commit to a design.
| Capability | OpenFGA | Ory Keto |
|---|---|---|
| Authorization model (schema and type definitions) | Native model per store, based on the Zanzibar relationship approach; Auth0 FGA runs on the same open-source engine, so models are closest to port | Namespaces and relation definitions in configuration; the model language differs, so expect to rewrite models rather than copy them |
| Stores or namespaces (isolated permission data) | Stores hold separate models and tuples; confirm store limits and the store-per-tenant pattern for your scale | Namespaces are defined in configuration; confirm how multi-tenant isolation maps to your application design |
| Relationship tuples (write and delete) | Supported through the write API; tuples are the core data to migrate from Auth0 FGA | Relation tuples are supported through its read and write APIs; confirm batch write behavior for your volumes |
| Check queries (yes or no decisions) | Supported and central to the design; verify latency against your data model in testing | Supported as permission checks; verify latency and consistency settings with your own tuple volume |
| List queries (objects a user can access) | Supported in the OpenFGA API; confirm the exact response limits for your API version | Supported through list relation tuples queries; confirm filtering needs for large result sets |
| Bulk import and export of tuples | Confirm the current export and import path in the OpenFGA docs for your version; plan to script migration from Auth0 FGA exports | Confirm available bulk tooling for your version; plan to script migration and test restore procedures |
| Storage backend | PostgreSQL 14 or later, MySQL 8 and SQLite (beta) as supported in the supplied facts; SQLite is not for production planning | Confirm supported database engines against the current Ory Keto documentation before you size the database |
| SDKs and client libraries | Official SDKs exist; confirm feature parity with the Auth0 FGA SDK functions your application calls | Client access is mainly through its APIs; confirm which language clients you can reuse and what you must write yourself |
| Hosted operations (upgrades, backups, patching) | Self-hosted; you run upgrades, backups and monitoring, or you contract an implementation partner to do so | Self-hosted in the open-source edition; the Ory Enterprise License adds commercial support and CVE patch commitments, as described in the Ory documentation |
OpenFGA, Ory Keto and the alternatives to weigh
Auth0 FGA is built on OpenFGA, so OpenFGA is the closest self-hosted match in model and API. Ory Keto follows the same Zanzibar lineage with a different feature set, and in-application checks remain a valid choice for small, stable permission models. Each option below trades off operational load, modeling effort and where permission data lives.
OpenFGA as a self-hosted service
OpenFGA is the Apache-2.0 project behind Auth0 FGA, which has run it in production since December 2021, so its authorization model language and API are the closest match to what your teams already use. It is a CNCF incubating project. You run it as a separate service that your applications call on every check. Confirm which storage backend you will use (PostgreSQL 14 or later, MySQL 8, or SQLite in beta) and whether the version you deploy matches the model syntax your existing tuples depend on.
Ory Keto as a permission server
Ory Keto is an Apache-2.0 permission server based on Google's Zanzibar approach, with support for ACL and RBAC models. It fits teams that already run Ory Kratos or Hydra and want permissions in the same stack. The trade-off is that its modeling approach and API differ from OpenFGA, so existing Auth0 FGA models and tuples will need to be rewritten and tested. Check whether the features you need, such as the modeling depth you rely on today, are in the open-source build or the Ory Enterprise License.
Checks written in application code
For a small set of stable rules, such as role checks on a few endpoints, permissions can live in your application code with no extra service. This removes a network hop and a database to operate. The cost moves to your developers, who must keep the rules consistent across services and write their own audit and testing around them. It becomes hard to manage once relationships such as nested folders, teams or customer organizations multiply, so define a threshold for when you will move to a Zanzibar-style service.
Permission rules stored in PostgreSQL
Permission relationships can be stored in PostgreSQL tables and checked with queries or a thin internal API. This suits teams with strong SQL skills and modest authorization graphs, and it keeps backup, access control and encryption with the database you already operate. The main risk is that you build the check semantics, caching and consistency yourself, which is the work OpenFGA and Keto already do. Ask whether your security team will accept a custom authorization engine in its evidence and reviews.
How relationship-based checks replace Auth0 FGA calls
Relationship-based authorization replaces Auth0 FGA calls by storing permissions as relationships and answering yes or no questions against them. In the Zanzibar style used by both OpenFGA and Ory Keto, each fact is a *tuple* that links an object to a user through a named relation, such as document:roadmap with relation viewer and user user:alice. A separate *authorization model* defines what relations exist and how they combine, for example that anyone who is an editor of a folder also counts as a viewer of the documents inside it. Your application then sends a check request such as "can user:alice view document:roadmap?" and the server walks the tuples and the model to return allowed or denied. The application does not hold the permission logic itself, so the same answer applies in every service that calls the server.
OpenFGA extends the Zanzibar approach beyond pure relationships to role-based and attribute-based use cases, so a single model can express roles, group membership and conditions on request attributes. Ory Keto supports access control lists and role-based access control, which covers many simpler rules but may need more modeling work for deep hierarchies. Confirm the exact modeling features each server exposes in its current documentation before you commit to one, since both projects change their model languages over time. Make the authorization model your first deliverable: write down the object types, the relations between them, and the ten or so check questions your product asks most often, then test those checks against sample tuples before any service depends on them.
Installing the server is the smaller part of the work. The main effort is deciding how your product's permissions map onto objects, users and relations, and keeping tuple writes in step with changes in your application database, such as when a user leaves a team or a document is moved. Plan for that synchronization, and for how a failed write is retried, before you migrate Auth0 FGA stores. Ask any implementation partner to show the model, the tuple write path and a set of regression checks as part of the written scope.
Keeping Auth0 login while the permission service moves
Moving authorization checks to OpenFGA does not require moving login at the same time. The decisions below connect the token your applications already receive from Auth0 to the relationship data OpenFGA stores, and each one depends on your architecture, so confirm them in your own environment before cutover.
Keeping Auth0 for authentication
Auth0 can keep issuing tokens and handling login while OpenFGA answers only the question of whether a subject may perform an action on an object. Your applications still validate the Auth0 token, then call OpenFGA with the verified subject. Confirm that your current token contains the claims you need, and that your team can run the two services with separate ownership and separate change windows.
Mapping the token subject to tuples
Every tuple in OpenFGA names a user, such as user:<id>, and that identifier must match what your application extracts from the sub claim. Auth0 subjects often look like auth0|... or google-oauth2|..., so decide whether tuples store the raw value or a stable internal ID. Test this mapping with users who log in through social and enterprise connections, not just database users.
Placing the permission service
Decide whether OpenFGA runs in the same cluster as your applications, beside Auth0's tenant boundary in your own network, or in a separate security zone. Check which systems can reach its gRPC and HTTP APIs, who can write tuples, and how the service authenticates callers. Placement also determines whether an outage in one component blocks authorization for every application.
Handling Auth0 Organizations identifiers
If your tenants use Auth0 Organizations, the org_id claim may need to appear in tuple names or in contextual checks so that a user in one customer organization cannot match permissions granted in another. Decide whether organization membership lives in OpenFGA, in Auth0, or in both, and document which system is the source of truth. Confirm the exact claim names in your tokens before writing the model.
Measuring added request latency
Each protected request may now include a network call to OpenFGA, so measure p95 and p99 latency per endpoint before and after the change. Consider caching checks in the calling service and confirm how stale cached decisions may be after a permission is revoked. Set an alert for check errors, because a failed check should deny access rather than fall through to a default allow.
Choosing a storage backend and hosting model for OpenFGA
PostgreSQL 14 or later is the storage backend most teams should plan around for production OpenFGA. Your team runs the OpenFGA service as a stateless component that reads and writes relationship tuples and authorization models in PostgreSQL, so the database becomes the system of record for every permission decision your applications depend on. Plan for a managed or self-managed PostgreSQL cluster in your own cloud account or data center, with the same backup discipline you apply to other systems of record.
- What you run: the OpenFGA server (containers or binaries), a PostgreSQL 14 or later primary, and at least one replica or standby, all inside your network boundary.
- What you back up: scheduled base backups plus continuous write-ahead log archiving, with restore tests on a separate environment. Tuples are not reconstructable from application data alone, so treat this database as critical.
- High availability: usually handled with streaming replication and a failover manager such as Patroni, or with the high-availability service of your cloud provider's managed PostgreSQL. Confirm the failover behavior your team has tested, not only the behavior advertised.
- Who owns it: a database or platform team that already runs PostgreSQL for other workloads. Authorization outages often trace back to database connection or failover issues, so application owners should know who to page.
- Upgrades: schedule major PostgreSQL upgrades and OpenFGA version upgrades as separate changes, and confirm compatibility in staging first.
Before you commit, ask your database team to confirm backup retention, restore time objectives and who signs off on schema or version changes.
MySQL 8 is a supported option when your organization already operates MySQL 8 as its standard relational database and has staff who run it well. The operational model mirrors PostgreSQL: OpenFGA stays stateless and the database holds all tuples and models. The main question is whether your MySQL platform team can meet the same recovery and availability expectations for an authorization datastore that sits on the request path of your applications.
- What you run: the OpenFGA service plus a MySQL 8 primary with replication, deployed in your own infrastructure or through a managed MySQL service in your cloud account.
- What you back up: full backups and binary logs with tested point-in-time recovery. Verify that restores reproduce the same tuple and model state, not just a database that starts.
- High availability: typically group replication, InnoDB Cluster, or a managed multi-zone MySQL offering. Ask the vendor or platform team how failover interacts with the OpenFGA connection settings in your environment.
- Who owns it: the team that already owns MySQL, with clear ownership of OpenFGA schema changes. If that team is smaller than the team running PostgreSQL elsewhere, plan for on-call coverage before go-live.
- Compatibility: confirm the supported MySQL 8 minor version against the OpenFGA release you plan to run, and test migrations between OpenFGA versions on that exact version.
Ask your DBA team to document the failover runbook and to confirm which OpenFGA version they have tested against MySQL 8 in staging.
SQLite is listed as beta storage for OpenFGA, so treat it as an evaluation and development option, not a production datastore. It lets a developer run OpenFGA on a laptop or in a CI job with no separate database server, which is useful for modeling authorization, writing tests and checking how your application calls the authorization API. Keep it out of any environment that holds real customer or employee permissions.
- What you run: the OpenFGA binary with a local SQLite file, usually on a developer machine or a short-lived test environment.
- What you back up: nothing formally. Instead, store authorization models and test tuples as code or fixtures so the environment can be recreated quickly.
- High availability: not applicable. A single file on a single host has no replication or failover, so availability depends on that host.
- Who owns it: the application or security engineers building the model. No database operations team is needed, but someone should own the decision to promote a model from SQLite testing to a production backend.
- Migration path: plan to move models and tests to PostgreSQL or MySQL before production, and rerun your authorization tests against the production backend.
Before you rely on any OpenFGA environment for a decision, confirm with the OpenFGA project which storage backends are supported for the release you run.
Migrating Auth0 FGA stores to self-hosted OpenFGA
This sequence moves authorization models and relationship tuples from hosted Auth0 FGA stores into a self-hosted OpenFGA instance, with checks proven side by side before any application traffic moves. The output is a staging store that matches production decisions and a documented, reversible cutover.
Confirm the export path with Auth0 first
Before any design work, ask Auth0 how your tenant's FGA stores, authorization models and tuples can be exported, which format the export uses, whether it is available on your plan, and how far back it reaches. Your platform team owns the question and the written answer goes into the migration record. The step is done when you know exactly which files you will receive and can name the person at Auth0 who confirmed it. Do not start the other steps until this answer is in writing, because every later step depends on it.
Inventory stores, models and tuples
List every FGA store in use, including development and staging stores, and record the active authorization model version for each. For each store, count the tuples by object type and relation, and identify which applications call it for checks, list, and write operations. Also note any tuples written by background jobs or user-facing administration screens, since those paths must be reproduced in your own code. The output is an inventory sheet that maps each store to its consuming services and its owners, and it becomes the scope baseline for the rest of the migration.
Translate the model and test it against sample checks
Rewrite each Auth0 FGA authorization model in OpenFGA's modeling language and load it into a local OpenFGA instance. Build a test suite of sample check requests with expected results taken from production decisions, covering direct grants, inherited relations, and denials. Run the suite until every expected result matches. The output is a version-controlled model file and a passing test set, and the team should keep the test set because it is reused during shadow checks and by future model changes.
Load tuples into a staging OpenFGA
Deploy OpenFGA in staging with a supported storage backend, such as PostgreSQL 14 or later, following the project's documentation at openfga.dev. Transform the exported tuples into the write format that OpenFGA expects, then load them in batches and record counts per store and object type. Compare the loaded totals with the inventory from the earlier step. The step is complete when the counts match, the staging store returns the same results as the test suite, and the transformation script is saved with the migration record.
Run shadow checks against both systems
Route a copy of live check requests to both Auth0 FGA and the staging OpenFGA, without letting the OpenFGA answer affect users. Log every disagreement with the request, the tuple state, and the model version, then fix the cause, whether it is a model translation error, a missing tuple, or a timing difference from writes that happen during the export. Keep running shadow checks across the normal business cycle, including batch jobs and administrative changes, so that rare paths are covered. The output is a mismatch log that is empty for the agreed window, and this evidence supports the cutover decision.
Define rollback criteria and cut over in stages
Agree in writing on the conditions that trigger a rollback, such as a check mismatch rate above zero for the agreed window, latency beyond the target, or write failures. Then move calls service by service or by a small share of traffic, starting with low-risk read paths and leaving write paths for later. Dual-write new tuple changes to both systems until the last service has moved. The step is done when every service reads from OpenFGA, each cutover has a logged owner and time, and the rollback procedure has been rehearsed in staging.
Retire the hosted store after rollback criteria are met
Once the agreed observation period has passed with no rollback triggers, stop dual writes and set Auth0 FGA stores to read-only for a final reconciliation check against OpenFGA. Keep an exported copy of the tuples, models, and logs under your retention policy, and confirm with Auth0 what happens to data in the store when it is deleted. Remove the hosted store credentials from application secrets and update the architecture records. The output is a signed-off decommissioning record and a sealed archive, so audit and incident response teams can still reconstruct past decisions.
What does replacing Auth0 FGA cost and how long does it take?
What are the main cost components of replacing Auth0 FGA with a self-hosted service?
The cost splits into one-time work and recurring running costs. One-time work covers modeling your authorization logic as an OpenFGA or Keto model, writing and testing the calls from each application, and migrating existing relationship data. Recurring costs cover the compute and storage for the permission service, a PostgreSQL or MySQL database with backups and patching, monitoring, and the staff time or retainer that keeps upgrades and security fixes current. Infrastructure is paid to your cloud or data center provider, while engineering and any outside help are paid by the hour, a fixed scope, or a retainer. Ask any quote to list each component separately so you can see which part recurs.
What makes the migration take longer or shorter?
Effort rises mainly with the number of object types and relationships in your model, how much authorization logic is currently hard-coded in application code, and how many applications call the Auth0 FGA API. A small model used by one service is a contained change. A model with many resource types, inherited roles and several services that each check permissions needs more design review, more integration tests and a staged cutover. Existing authorization data that must be exported and re-written into the new store also adds time. Ask the vendor or partner to size these three inputs before agreeing a schedule.
What does the client's team need to provide during the engagement?
Your team needs to name an owner for the authorization model who understands business rules, usually a senior engineer or architect. Someone must confirm which permissions exist today, who is allowed to change them, and which applications depend on them. You also need access to the current Auth0 FGA store and its tuples, a staging environment that matches production networking, and a decision on where the service runs and how it is backed up. Without these inputs, model design and testing tend to stall. Put the client responsibilities into the written scope so both sides know who approves each stage.
Can our own engineering team replace Auth0 FGA without outside help?
A team with experience in relationship-based authorization and container operations can often do it internally, especially for a single application with a small model. The harder parts are modeling edge cases such as inherited permissions and revocations, load testing the check path, and setting up high availability and backups for the database. OpenFGA and Ory Keto are both Apache-2.0 projects, so there are no license fees to pay, but staffing time is a real cost. Choose outside help when the model is large, when several teams depend on the result, or when you need documented controls for an assessment. Whichever path you take, confirm the support options you need from the project and your own staff.
What does Ory Enterprise License cover that the open-source servers do not?
Ory Enterprise License is a commercially supported build of Ory's self-hosted servers. It adds enterprise features such as Kratos multi-tenancy and organizations, plus 24/7 support SLAs and timely CVE patches. Ory states that open source fits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Keto is part of the Ory stack, but the license terms and price for it are set by Ory, so ask for a written quote that names each product and feature. If you pick OpenFGA, compare its community support and your own patching plan with what a commercial agreement would provide.
What should a written quote for this work include?
Ask for a written scope that lists the authorization model, the number of applications and integrations in scope, the storage backend and its high availability design, and the testing and cutover approach. The quote should separate one-time implementation from recurring support, upgrades and testing, and state what the client team must supply. Request the deliverables, the acceptance criteria and the change process for scope adjustments. Also ask how timelines are set, what happens if the model grows during the project, and which licenses or subscriptions are charged separately. Compare every quote against the same written scope.
What ongoing work follows the initial cutover?
After cutover, the permission service needs regular upgrades, database patching, backup restore tests, and monitoring of check latency and error rates. Models also change as products add features, so each change needs review and test coverage. Plan for a named owner, an on-call path and a change process from the first day. Some teams keep this in-house, while others take a retainer for upgrades and continuous testing. Ask any provider which of these tasks are included, how security fixes are delivered, and how long they are expected to take.
How DeployOpen scopes and delivers an FGA replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a fine-grained authorization replacement, we start from a written scope covering the authorization model, the storage backend and how the permission service runs beside your identity provider.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory which Auth0 FGA stores, authorization models and checks your applications call today, and which ones you need to keep.
- We confirm where the OpenFGA or Ory Keto service will run, which PostgreSQL or MySQL instance holds tuples, and who operates it.
How we build
- We draft the authorization model in a sandbox and test it against representative relationship tuples before any production data moves.
- We deploy the permission service in your cloud account, data center or air-gapped network, with the storage backend and network paths you approved.
- We build integration tests that compare check results from the old and new services for the same user, object and relation.
How we hand over
- You receive the authorization model, tuple schema, deployment configuration and runbooks for backup, upgrade and failover.
- Handover includes documentation of how each application calls the check and list APIs, and how model versions are rolled out.
- We provide evidence of access control testing and configuration that your internal reviewers or external auditors can examine. DeployOpen prepares this evidence but does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the service keeps pace with new releases.
- Security testing of the authorization layer, including API and access control tests, can be scoped separately from the migration.
- Ask us to confirm in writing which parts of support, patching and monitoring fall under your retainer before signing.
