FGA Permissions Index
Precompute permissions for instant verification of what users can access.
What Is A Permissions Index?
FGA works by remembering relationships — who has access to what and why. As you add more users, objects, and relationships between them, FGA builds a large graph of interconnected relationships. Checking whether a user has access to an object means finding one path through that graph that connects the two. If you want to find all the objects a user has access to, you have to travel every path and remember all the routes that exist.
Example: A -> B -> C, where A has a relationship with C through B.
The Permissions Index cleverly calculates all these possible relationships ahead of time. When a new relationship is added to FGA, the Permissions Index incrementally computes every access that the permission implies and saves those as direct paths (kind of like finding a "shortcut" path). Instead of walking the entire graph again to find all the paths every time someone asks "what objects does a user have access to?", you already know exactly how many objects a user has access to and thus can make an authorization decision faster.
Example: A -> C, where A has a relationship with C, completely skipping B.
The result is that access lookups become constant — no routing required at query time, just a direct check or list against pre-calculated connections.
Analogy: think of it like a traveler who wants to get to their destination as quickly as possible. So when he gets to the airport, he gets on the first plane he sees, hoping he will eventually land at the right city. There is a connection somewhere; he just has to find it. Instead, the Permissions Index eliminates all layovers. It looks at the entire flight schedule possible ahead of time and books a direct flight for every known traveler. So instead of figuring out the route when someone shows up at the airport, the nonstop connection is already there waiting.
How It Works
The key innovation behind the Permissions Index is a calculated tradeoff: do the expensive work when permissions change, not when someone is checking for access.
Every time a relationship is written to FGA — a user added to a team, a team granted access to a folder — the Permissions Index immediately follows the consequences of that change through the entire graph and incrementally computes every new direct relationship combination. The result is a continuously updated table of "flattened" permissions: every user, every object, every relation, already determined.
This is a well-established database technique called Materialized Views — storing the result of a computation so you don't have to recompute it on every read. The Permissions Index applies this pattern specifically to authorization data, keeping the view continuously in sync across every possible combination of "who can do what to which object" as exactly defined by your authorization model.
Since permissions can now be precomputed at Write time, answering "what can this user access?" at Query time can skip the complex graph traversal and become a constant-time lookup.
What Problems Does It Solve?
Once you implement fine-grained authorization (FGA) to protect your resources, where business data lives in one system (your application database) and authorization data lives in another system (FGA), querying two separate data sources while respecting speed, sorting, and access control becomes extremely difficult.
Use Case 1: Enterprise Search - Permission-Filtered Results
Enterprise search is one of the most common — and most difficult — authorization challenges to perform at scale. Companies store hundreds of thousands of documents, contracts, tickets, and records across many systems. When someone searches, the results must be filtered to show only what that user is allowed to see. This problem is often called "Search With Permissions".
Use Case 2: "Chat With My Data" — Permission-Aware AI Agents
One of the most requested AI features by enterprises is a "chat with my data" agent — a conversational interface that lets users ask natural-language questions about their data. These systems typically use a Retrieval-Augmented Generation (RAG) architecture: relevant documents are retrieved from a data store and passed to a language model as context for generating an answer, but only using documents a user is authorized to see.
What makes RAG more difficult is that many enterprises execute their AI "Retrieval" queries inside their own managed data platforms — Snowflake, Databricks, BigQuery. Calling an external HTTP service like FGA per row at query time is infeasible or impractical at scale. The authorization data ideally needs to already be in the data platform before the query even runs.
Index Locations
The Permissions Index listens to writes made to FGA and continuously computes permission changes. But depending on the index location, it changes how you interact with your Permissions Index.
Colocated
With a colocated index, Auth0 FGA streams the expansion changes (as INSERTs or DELETEs) back to you to be stored next to your application data. Answering "what can this user access?" becomes a simple lookup or SQL join (even across millions of objects), rather than waiting for a remote API call to finish and return.
Hosted
With a hosted index, Auth0 FGA stores the expansion changes in a Permissions Index for you, providing faster responses to existing FGA endpoints, such as the Check or ListObjects endpoints.
Note: The Permissions Index is initially available as a colocated option only. We plan to offer a hosted option soon.
Current Limitations
Authorization Models
The Permissions Index does not support the following FGA modeling features (yet):
- conditions
- contextual tuples
- wildcard on the left side of
but not
Your authorization model can still contain any of these modeling patterns, but they cannot appear on the indexable path.
Index Creation
Note: In Developer Preview, index creation and model attachment are manual operations. To create an index or attach a new model, reach out to your Auth0 FGA Account Executive (AE) or Technical Account Manager (TAM). Self-Service index creation and model attachment are in scope for General Availability (GA).
Eventual Consistency
The Permissions Index was designed for workloads that are eventually consistent. After a tuple is written to FGA, there is a short delay before the corresponding expansion is reflected in the index. This is called freshness. Your application should be able to tolerate some freshness lag — for example: "I only want results that are at least 15 seconds fresh." Permission decisions that require absolute correctness at the exact moment of the request should use Check or ListObjects in higher_consistency mode. See Best Practices for the recommended fallback pattern when freshness exceeds an acceptable threshold.
During Developer Preview, the Permissions Index works best when tuple writes are routed through a single primary FGA region. Writing across multiple regions can introduce ordering challenges, so the service may briefly defer processing changes to reduce the risk of out-of-order updates. Occasional cross-region writes are supported, but for the most consistent and predictable freshness, a single-region write pattern is recommended. We are actively working on improvements to support multi-region writes with predictable freshness guarantees, which is in scope for General Availability (GA).