List Filtering with Oso
Why Filtering Lists Is Hard
When you’re building your app, you don’t just need to answer questions like “Can Alice view this document?”— you also need to answer “Which documents can Alice view?”
Seemingly simple questions like these often require hand-written recursive SQL or post-query access checks.
This approach results in:
Slow performance: Per-row checks don’t scale
Duplicated logic: Authorization scattered across services
High latency: Repeated calls to the authorization engine
What you really want is a query that returns only what the user is allowed to access.
Centralized Policy, Local Data Filtering
Answer "What can I see?" with a single query: Oso generates filters from your authorization policy so your database returns only authorized results.
Oso supports two list filtering methods:
listAPI: Ask Oso Cloud for all resource IDs a user can accesslist_localAPI: Oso generates a SQLWHEREclause that filters your own database
With list_local, you enforce centralized policies using local data, no need to sync every record to Oso.
Example:
SELECT * FROM documents
WHERE <oso-generated WHERE clause>
The permissions layer for dashboards, feeds, and search
Bulk Checks
Convert thousands of is_allowed() calls into a single query.
Hybrid Data Model
Keep large or sensitive datasets local to avoid syncing and query them directly.
Explainability
Debug access decisions with decision logs and explain.
Optimized SQL
Integrates with sorting, pagination, and indexes.
