Last updated: September 2026
Auth0’s FGA Permissions Index solves one specific problem: filtering a large result set by permission without asking the authorization service about every row. It does that by moving the expansion work from query time to write time, precomputing permission combinations so your search layer can join against them. If that is the problem you have, it is a genuinely good answer. If your problem is “can this user perform this action on this object,” Keycloak Authorization Services already answers it, and you do not need a vendor-hosted index to get there.
The distinction matters because ReBAC conversations collapse the two. Relationship-based access control describes how you model permissions. A permissions index is an implementation detail about where the graph traversal happens. Picking a platform because of the second when you only need the first leaves teams paying for infrastructure they never query.
What does Auth0 FGA Permissions Index actually ship?
Auth0 put the FGA Permissions Index into developer preview in 2026, described in its post “Auth0 FGA Permissions Index Is Now in Developer Preview” and documented at docs.fga.dev. It flattens ReBAC relationships into precomputed permission rows so applications can do low-latency permission-aware search and retrieval-augmented generation over large corpora.
The architectural claim is straightforward. Traversing a relationship graph at request time is expensive when a single query touches thousands of objects, so the index anticipates that traversal and stores the result. Reads get cheaper and writes get more expensive. A design that materialises permissions at write time almost certainly carries some propagation delay between a permission change and the index reflecting it, though the exact guarantees are Auth0’s to state.
That delay is the part worth checking during evaluation. Auth0’s own docs are where to confirm the guarantees at your write volume, because the answer determines whether you can serve a revocation-sensitive surface from the index or need a live check alongside it.
Availability is the other practical gate. During the preview, getting an index set up is arranged through Auth0 rather than self-serve, so this is not a feature you evaluate by signing up on a Tuesday afternoon.
Where did ReBAC come from, and why does everyone cite Zanzibar?
Every ReBAC product in this category traces to one paper: Google’s description of the authorization system behind Drive, YouTube and Cloud, published at USENIX ATC in 2019 as “Zanzibar: Google’s Consistent, Global Authorization System.” It introduced the relationship tuple as the unit of authorization and the consistency tokens that make distributed checks coherent.
The model is small enough to hold in your head. You store tuples of the form object#relation@subject, for example document:roadmap#editor@user:anne. You ask Check whether a subject has a relation to an object. You ask ListObjects for everything a subject can reach through a relation.
OpenFGA, a CNCF project that Auth0 originally open-sourced, implements that model and is what Auth0 FGA is built on. You can run it yourself. The API surface you write against is the same whether you self-host OpenFGA or buy the managed service, which is the single most useful fact in this whole comparison: your authorization model is portable even when the index is not.
For readers newer to the vocabulary, we cover the underlying distinction between attribute-driven and relationship-driven models in our ABAC explainer.
What does Keycloak Authorization Services already do?
Keycloak ships a full policy decision point in the box. Authorization Services in Keycloak 26.x models resources and scopes, evaluates them against policies of several types, role, group, client, client scope, user, time, regex and aggregate, and issues a Requesting Party Token through the UMA 2.0 grant at the token endpoint:
curl -X POST
-H "Authorization: Bearer $ACCESS_TOKEN"
-d "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
-d "audience=my-api"
-d "permission=roadmap-doc#edit"
"https://auth.example.com/realms/myrealm/protocol/openid-connect/token"The permission parameter takes Keycloak’s own resource#scope form, not Zanzibar tuples. The response is an RPT carrying the permissions that were granted, or a 403 when the policies say no. JavaScript policies also exist, but they ship as a deployed JAR with the scripts feature enabled rather than as something you author in the console.
That covers the “can this user do this to this object” question directly, including per-resource instance permissions, without a second system. The built-in policy evaluation endpoint lets you test a decision against a specific user and resource before you ship it, which is the part teams miss when they assume Keycloak only does role checks.
One precision point, because the names collide. Fine-Grained Admin Permissions, FGAP, delegates administration of the Keycloak realm itself, while Authorization Services is the application-facing PDP. They are not separate engines: Keycloak’s own admin documentation states that “Fine grain admin permissions were implemented on top of Authorization Services,” and FGAP v2 models the admin permissions client as a resource server. Same machinery, different job, and treating them as interchangeable features is what produces wrong evaluations. We separate them in the Keycloak fine-grained authorization explainer and go through the policy types individually in the policy types guide.
Where Keycloak Authorization Services is genuinely weaker is deep relationship traversal. Modelling “everyone who can edit any document in any folder this team owns, three levels up an arbitrary hierarchy” is not what its policy engine is shaped for. That is the case where a Zanzibar-style store is worth the extra system.
Which should you pick: Auth0 FGA, OpenFGA, Keycloak, or Keycloak plus OPA?
Pick by the question you are asking at request time, not by the vendor you already have.
| Your actual need | The fit | What it costs you |
|---|---|---|
| Point checks on resources and scopes, tied to your IdP | Keycloak Authorization Services | Limited deep graph traversal |
Deep relationship graphs, ListObjects at scale |
OpenFGA, self-hosted | You run and scale the tuple store |
| Permission-filtered search or RAG over large corpora | A permissions index, Auth0 FGA or equivalent | Write amplification and a consistency window |
| Policy as code, non-relationship rules, shared across services | Keycloak plus OPA | Two systems, two review paths |
The combinations are common and legitimate. Keycloak handles authentication and issues tokens carrying the claims your policy layer needs; OPA or OpenFGA answers the authorization question that needs a different engine. We walk through that pairing in the Keycloak and OPA post.
What we would push back on is adopting a managed permissions index because ReBAC sounds modern. If you cannot name the query that is slow today, the index is solving a problem you do not have, and you have added a system that must stay consistent with your identity data.
What does lock-in look like in this category?
The authorization model is portable. The index is not, and neither are the operational assumptions you build on top of it.
Because Auth0 FGA is built on OpenFGA, your type definitions and tuples map to a self-hosted OpenFGA deployment with far less friction than a typical migration. That is a real advantage of this category over proprietary policy languages. The part that does not move is everything downstream of the index: the write-path latency budget, the consistency guarantees your search layer assumes, and any application code that reads precomputed rows directly from a database the vendor populates.
The identity side is where lock-in usually bites harder, and it is worth separating the two decisions. Users, credentials, federation and sessions are a much stickier dependency than a set of relationship tuples. Teams comparing the full stack rather than just the authorization layer usually want our Keycloak versus Auth0 comparison alongside this, and the Auth0 alternatives roundup if the evaluation is already underway.
Running Keycloak as your identity management service and pairing it with OpenFGA for the relationship graph keeps both halves exportable, which is the configuration that tends to hold up best as a product grows.
Frequently asked questions
What is ReBAC, and how is it different from RBAC and ABAC?
Relationship-based access control derives permissions from relationships between subjects and objects, such as “editor of the parent folder.” RBAC assigns permissions through roles, and ABAC evaluates attributes on the request. ReBAC handles hierarchy and inheritance natively, which is what makes it suit document and workspace models.
Can Keycloak do ReBAC?
Keycloak Authorization Services can express relationship-shaped rules through resources, scopes and aggregate policies, and it handles per-instance permissions well. It is not a Zanzibar-style tuple store, so deep or arbitrary-depth traversal and large-scale ListObjects queries are better served by pairing Keycloak with OpenFGA.
Do I need a permissions index?
Only if you filter large result sets by permission. The index exists to make permission-aware search and RAG retrieval fast. If your authorization questions are point checks on a single object, a live Check call answers them without the write amplification or the consistency window.
Is Auth0 FGA the same as OpenFGA?
Auth0 FGA is the managed service built on OpenFGA, the CNCF open-source project Auth0 originally released. The core model and API are shared, which makes the authorization model portable. Managed-only features such as the Permissions Index are not part of the open-source project.
What happens to permission changes while the index catches up?
That depends on the consistency guarantees of the specific index, which is a question for the vendor’s documentation at your write volume. The general pattern for revocation-sensitive operations is to keep a live check in front of them and use the index for the read-heavy filtering it was built for.
Sources
- Auth0, “Auth0 FGA Permissions Index Is Now in Developer Preview”, 2026, retrieved 2026-09-20, https://auth0.com/blog/auth0-fga-permissions-index-developer-preview/
- Auth0, “FGA Permissions Index”, Auth0 Fine-Grained Authorization documentation, retrieved 2026-09-20, https://docs.fga.dev/permissions-index/fga-permissions-index
- Pang, Ruoming et al., “Zanzibar: Google’s Consistent, Global Authorization System”, USENIX ATC, 2019, retrieved 2026-09-20, https://www.usenix.org/conference/atc19/presentation/pang
- OpenFGA, project documentation, retrieved 2026-09-20, https://openfga.dev/docs/fga
- Cloud Native Computing Foundation, “OpenFGA”, retrieved 2026-09-20, https://www.cncf.io/projects/openfga/
- Keycloak, “Authorization Services Guide”, retrieved 2026-09-20, https://www.keycloak.org/docs/latest/authorization_services/index.html