Authorization is a problem as old as computers. But until recently, there haven’t been good, off the shelf solutions for it. That’s changing. The are a variety of companies that are trying to solve this problem, including Oso. The increasing number of options is both great and confusing.
What’s the right tool for the job? This post provides specifics on when to use Oso, and when not to.
What is Oso Cloud
Oso Cloud is authorization as a service. Concretely, it consists of the following pieces:
- A DSL for writing authorization logic, called Polar, which we build and maintain (in Rust)
- Oso Cloud, the service, which stores authorization data (like roles) and responds to permission checks and related questions over an HTTP API. Our servers are replicated globally for <10ms latency and >99.99% uptime.
- Clients for most popular programming languages, database integrations, and a CLI for interacting with our APIs.
- A UI that lets you interact with our APIs, as well as additional tooling, like logging and a debugger.
What is a good use case for Oso Cloud?
You’re building a custom application
Oso Cloud is for authorization in an application that you build (i.e., not for a SaaS app you buy, not for access to infrastructure). Application authorization has a unique set of challenges, most of which center on how to model everything your users want and how to wrangle the data you need in order to return the right responses. The following sections describe these challenges and the design decisions we’ve made to solve them.
You have complex authorization requirements
At some point, you can’t keep your authorization logic in your head any more. It becomes difficult to reason about, to debug, to change. When this happens, Oso Cloud could be a good fit. Here are some patterns and features that create this kind of complexity:
- Fine-grained authorization - Providing access control at the resource level (e.g., individual files/folders), with support for hierarchical, relationship-based permissions and implied permissions (e.g., an owner of a parent folder automatically has owner permissions on child files)
- Collaboration - Letting your users share resources (e.g., files) and expose different permissions on those resources (e.g., view, edit, comment)
- Custom roles - Giving your enterprise customers the ability to define their own custom roles
Why Oso is a fit: Oso Cloud equips developers with Polar, our DSL for authorization. Polar is able to express the most complicated logic in a clear, straightforward syntax that is easy to read, reason about, and debug.
Further reading: The 10 Types of Authorization: The Families of RBAC, ReBAC and ABAC
You want to centralize authorization across your org
As organizations grow, it’s common to centralize shared functions and services. Authorization is often built with ad hoc code spread throughout an application. If you want to centralize authorization to provide consistency, visibility, and leverage for your application development teams, Oso could be a fit.
Why Oso is a fit: Oso Cloud gives you a single place to store, maintain, and audit all authorization logic. It provides a single approach for writing, testing, and debugging this logic, as well as comprehensive documentation that all app teams use to implement authorization features according to best practices.
You have more than just a monolith
Arguably the hardest problem to solve in authorization is how to bring together disparate pieces of data to resolve a single authorization decision. You don’t have this problem in a monolith because all the data is…right there in your database. When you have multiple services or microservices, however, now your data is spread out. This creates new challenges, like:
- List filtering - How do you filter lists when some of the data is stored in your authorization service (e.g., resource IDs) and the rest of the data is still in your app databases (e.g., resource metadata)?
- Syncing & Reconciliation - How do you keep shared authorization data in sync between the app services and your authorization service (in this case, Oso Cloud)? How do you detect drift between the app services and your authorization service?
Why Oso is a fit: Oso Cloud supports a hybrid architecture for authorization data, where shared data lives in Oso Cloud and service-specific data stays in your application databases. Oso’s sync and reconciliation tools make sure the shared data stays in sync. Oso’s list filtering feature allows you to refine coarsely-authorized result sets with additional context from your application data.
Further reading: Managing Authorization Data in Microservices, Google Zanzibar for the rest of us
You’re building an LLM-based app
The same challenges described above typically apply to applications built on top of LLMs. You may have complex rules about who is allowed to see what data, and you want to ensure that your LLM-based app respects those rules. Even harder, how do you stitch together data in your app database, a vector database, and your LLM to ensure that any responses from the LLM filter out responses that the user shouldn’t be allowed to see?
Why Oso is a fit: You can easily apply the same mechanism that Oso uses for filtering to responses from an LLM.
When should I consider something else?
You need authorization for infrastructure or an app you buy
If you want to gate access to internal infrastructure, you could use Oso, but the fit won’t be as strong. Specifically, you’ll probably want integrations that Oso doesn’t yet have. Similarly, if you’re trying to manage access in apps that you buy and administer (e.g., Salesforce.com), Oso has no way of controlling that because it needs to be integrated into the app itself.
You have simple authorization requirements
If you all you want to do is have a few, high level roles – e.g., admin/member – keep it simple. The power of Polar will probably be overkill for these scenarios, so it’s not worth introducing a new dependency and technology for your team to learn.
You have a monolithic application
Oso Cloud is designed for applications where the data lives in multiple places. If the data lives in one place – your monolith – then introducing Oso would add a second place for that data, which probably isn’t worth it. (If you’re reading this and feeling disappointed, don’t worry – we have a solution for monoliths too, which we’ll launch in the future.)
Summary
When all you have is a hammer, every problem looks like a nail — but sometimes, what you really need is a finely-tuned, authorization screwdriver. While we’ll expand use case coverage for Oso Cloud over time, we want to ensure that engineers considering it understand its strengths and weaknesses. If you’d like to discuss any of this with us or other developers working on authorization, join us in the Oso Slack Community.
