
Who Oso Cloud is for#
SaaS teams centralizing permissions
Use Oso Cloud when RBAC, relationship permissions, and resource checks need one policy model across services.
Skip if:
You need a fully self-hosted, actively maintained open source authorization server today.
Developers testing authorization logic
Use Oso when permissions should be unit tested and debugged through a single interface.
Skip if:
Your app has only a few static admin checks.
Polyglot teams sharing policy concepts
Use Oso when Node, Python, Go, Ruby, Rust, or Java services need consistent authorization semantics.
Skip if:
Your organization requires all authorization to live inside one identity provider dashboard.
The problem it solves#
Authorization grows from a few role checks into a cross-service policy problem. Teams need to answer who can do what on which resource, filter collections by access, and test permissions before deployment. If those checks live throughout application code, every new enterprise requirement becomes a risky refactor and a security audit burden.
How it solves it#
Authorization modeling primitives
Oso supports common patterns such as RBAC and relationship-based access through built-in primitives and the Polar policy language.
Collection filtering support
Oso handles authorization beyond yes or no decisions, including filtering records to only those a user can see.
Policy testing workflow
Oso provides a single authorization interface that teams can unit test, debug, and reason about separately from scattered application checks.
Multiple language libraries
Node.js, Python, Go, Rust, Ruby, and Java libraries help teams apply the same authorization model across a polyglot stack.
Strengths and trade-offs#
Strengths
- Focused authorization layerOso is useful when teams want authorization logic modeled explicitly instead of hidden inside controllers and database queries.
- Good fit for service authorization questionsOso Cloud's positioning around `oso.authorize(user, action, resource)` makes the core integration pattern easy to understand.
- Language breadthMultiple SDKs help teams apply the same authorization model across a polyglot stack.
Trade-offs
- -Legacy library is deprecatedThe legacy Oso open source library is deprecated, though not end-of-lifed. Teams that need a fully self-hosted authorization layer should verify Oso's current open source roadmap before adopting.
- -Cloud product changes the ownership modelOso Cloud may be easier than self-hosted policy infrastructure, but teams seeking fully self-hosted authorization should verify current open source options.
What it's built on#
- Languages
- GoJavaPythonRubyRustTypeScript
- Databases
- SQLite
- Tooling
- esbuildWebpack
FAQ#
What is Oso used for?
Oso is used to model, test, and enforce application authorization policies such as roles, relationships, and resource permissions.
Is the Oso open source library still active?
The legacy open source library is deprecated but not end-of-lifed, with support and critical bug fixes continuing.
Which languages does Oso support?
Oso supports Node.js, Python, Go, Rust, Ruby, and Java libraries.
Similar open-source tools#
Warrant
Run fine-grained authorization with RBAC, ABAC, and ReBAC
Logto
Multi-tenant auth platform with SSO, RBAC, and social login
ZITADEL
Open source identity platform with SSO, RBAC, and multi-tenancy
Better Auth
Drop-in TypeScript auth with MFA, SSO, and multi-tenancy support
Cerbos
Move access control out of app code into testable YAML policies
iptv
A collaborative database for TV channels

