FAQs
What is Oso Cloud exactly?
Oso Cloud is authorization as a service (opens in a new tab). It helps you model common authorization patterns, test your configuration, and check authorization decisions at runtime.
Concretely, it consists of the following pieces:
-
Workbench, a visual rules editor for describing who’s allowed to do what in your app. Under the hood, this is fully extensible and backed by Polar, our declarative configuration language for authorization.
-
Oso Cloud, the service (built in Rust 🦀), 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 Node.js, Python, Go, Ruby, .NET (Java coming soon!)
-
Tools to give you short and tight feedback loops, like a VS Code extension, unit tests, a debugger, and logging.
Read On
Is Oso based on Google Zanzibar?
No.
We borrow some ideas from Zanzibar – e.g., facts are a kind of extension of tuples in Zanzibar. But fundamentally Oso is a logic engine under the hood, and it’s been this way since the first version of Oso in 2020. This design decision has proven key to making Oso flexible. This flexibility shows up in a number of ways – i.e., to express any scenario required in Polar, to query Oso along any dimension, and to get observability out of the platform. It also means Oso is not beholden to any of the semantic or architectural limitations of Zanzibar implementations.
What data should I store in Oso Cloud?
When using Oso Cloud, you store your authorization policy and only the data necessary to perform authorization. Typically this is roles, permissions, groups, and any attributes that are primarily used for authorization (e.g., whether a resource is public or private).
Data to store in Oso Cloud
The table below shows some common authorization models and the types of data you'd store in Oso Cloud for each model.
| Authorization Model | Example Policy Rules | Example Data Stored in Oso Cloud |
|---|---|---|
| Role Based | Admins can add new members. | Holden has the role admin in organization GillCorp. |
| Relationship Based | Any member in an organization can see repos in the organization. | Juno is a member of the organization GillCorp. |
| Attribute Based | Anyone on the public internet can read public repos. | Repo xyz555 is public. |
Data you don’t need to store in Oso Cloud
You probably won't store all authorization-relevant data in Oso Cloud. Specifically, data that you use heavily in other parts of the application and that change often you might just keep in your application database (like relationships between files and folders). For these cases, you can just send that data as context at request time. Here are some examples:
| Authorization Model | Example Policy Rules | Example Contextual Data Sent at Request Time |
|---|---|---|
| Nested resources | You can delete comments on an issue if you own the issue. | Issue pqr123 is the parent of comment abc999. |
| User-resource relationships | The writer of a comment can edit that comment. | Willow is the writer of comment abc999. |
Read on
How do you secure Oso Cloud?
We secure Oso Cloud using operational practices that create reliability for our business and mitigate security risks. Here are some of the things we do:
- Require Single-Sign-On and Two-Factor Authentication for all systems with customer data
- Enforce hardware-backed WebAuthN Two-Factor Authentication wherever possible
- Follow strict CI/CD practices and use automated tools to build, test, and release versions of Oso Cloud
- Collect and analyze logs from our critical vendors to assess security events in real time
- Maintain backups of critical infrastructure and practice our recovery procedures in the event of emergencies
We also take data privacy very seriously. While our operations practices minimize security risks, we also ensure that customer data is:
- Never shared with 3rd parties
- Kept securely within our VPCs and private AWS resources
- Stored using per-customer isolation
- Encrypted, both in flight to Oso Cloud and while at rest
Read On
What is Polar?
Polar is Oso's configuration language. It is a declarative, logic-based language that is optimized for handling the ambiguity inherent in writing authorization policies. Most folks can learn the basics in an hour. We build and maintain Polar as a key part of our open source authorization framework.
Read On
Does Oso do authentication or user management?
No, Oso assumes that you have a system in place for authenticating users and that you're storing user data elsewhere (e.g., in a database, hosted service). You can use user information as parameters in rules, but Oso is not a substitute for an identity or authentication provider.
Read On
Talk to an Oso Engineer
If you'd like to learn more about using Oso Cloud in your app or have any questions about this guide, connect with us on Slack. We're happy to help.