Mathieu Larose

Authorization as a Service: Data Filtering is Still Hard

January 2026

Authorization as a Service (AaaS) providers like Authzed, Cerbos, OpenFGA, Oso, Permify, and Permit have become popular in the last few years. Their core promise is that by centralizing authorization logic in a dedicated service, you save engineering effort and reduce the risk of authorization bugs. So, instead of building and maintaining your own authorization system, you rely on an external service and focus more on your core business.

This works extremely well for check queries such as "Can Mary view Document 1?", where the answer is true or false.

However, it's a completely different story for queries like "Which documents can Mary view?". In these cases, we need to return a list of resources that 1) the user is allowed to access, 2) are filtered by some attributes, and 3) sorted by some criteria, and all of which must be done efficiently.

For some providers, their recommended solutions to handle this type of queries have major gaps that require engineering teams to invest considerable effort and introduce additional complexity to their stack, to the point where we may question whether Authorization as a Service is worth it.

The Data Filtering Problem

The data filtering problem can be summarized as "Given a search filter and a sort order, which resources can the user view?".

A classic example is the Google Drive homepage. Documents can be filtered (e.g., "Show only PDFs"), and sorted (e.g., "Last opened"), and users should only see documents they are authorized to access.

Answering these types of queries is challenging because using an AaaS forces a separation between authorization data and application data. Authorization data lives in the AaaS, where it's used to enforce access control, while application data lives in your database, where it's used for filtering and sorting. Or I should be more precise by saying it's the index of the authorization data and the index of the application data that are separated, because in your database, you already all have the information needed to make authorization decisions, it's not optimized to do so.

This is because the main job of an AaaS is to build an index that efficiently answers authorization queries, while the main job of your database is to build an index that efficiently answers application queries.

As a result, we end up with two separate data silos. The challenge is finding a way to combine these indexes to efficiently serve queries like "Given a search filter and a sort order (application data), which resources can the user view (authorization data)?".

Solutions proposed by the AaaS providers

So let's look at the solutions that AaaS providers propose for the data filtering problem. I've written a summary below, but you can find more details in the references at the end of this post.

1. Search, then check

In this approach, you first query your database for potential resource IDs based on your filters and sort order. Then you pass this list to the authorization service to check which ones the user can access.

This method works well when your search results are small, but it does not scale when the database returns thousands or millions of resources, which is the case for most real-world use cases.

2. Check, then search

It's similar to the previous solution, but the order is reversed. You first ask the authorization service for all the resources the user is allowed to access. Then you filter and sort these results using your database.

This method only works efficiently if the user has access to a relatively small number of resources. Otherwise, you run into the same problem as before: transferring a huge list of IDs between the authorization service and your database does not scale.

3. Build a local index, then search

This strategy involves maintaining a local copy of the AaaS index in your database. You do this by listening to updates from the authorization service and indexing them locally. With both the authorization index and your application data index in the same location, you can join them efficiently to answer queries.

Unlike the previous two approaches, this method can scale. However, it adds complexity to your system because you need to maintain a copy of the authorization index. Most providers expect you to handle this yourself and provide very few details on how to implement it effectively. Some providers, like Authzed, offer a managed index that handles the local copy for you, but it doesn't seem be generally available yet.

A question I keep coming back to is whether this setup is really worth it. I send authorization data to the AaaS only to receive it back so I can index it locally. Would it make more sense to skip the AaaS entirely and use an authorization library that handles indexing directly within my system?

4. Get filter criteria, then search

Instead of asking the AaaS for a list of authorized resource IDs, you request a list of authorized filters and you then apply these filters in your database query.

Like the previous solution, this approach also has the potential to scale, but in practice you'll have integration work to translate the authorization filter into actual WHERE clauses and JOIN clauses.

Discussion

To me, it is not clear that AaaS providers drastically deliver on their promise of saving time and reducing authorization bugs. They certainly help, and conceptually I think they have the right approach. They have definitely helped me over the years to think more clearly about how to model authorization. But I feel we aren't yet at the stage of having "solved" authorization to the point of offering it as a service.

As usual, it depends on your use case. If your authorization queries are mainly check queries (e.g., "Can Mary view document 1?") and you need to scale these check queries, then an AaaS is an interesting offering.

But if a large portion of your authorization queries involve filtering on resources (e.g., "What documents can Mary view?"), then the scalability feature of the AaaS is largely voided. For these queries, the authorization load will be on your own servers (whether you choose the "build a local index" solution or the "get filter criteria" solution).

In cases like that, the benefits of a service would probably be better realized through a library. The problem is that libraries aren't easily monetizable. So the industry keeps pushing "services" even when a library would be a better technical fit.

It will be interesting to see how the space evolves and how providers improve their solutions for the data filtering problem.

References

Authzed:

Cerbos:

Google's Zanzibar:

OpenFGA:

Oso:

Permify:

Permit:

Like this article? Get notified of new ones: