Skip to main content
Oso Cloud is an authorization-as-a-service. It centralizes your authorization logic and exposes APIs for answering authorization questions.

​
How it works

  1. Define authorization policies in Polar, our DSL for expressing permissions logic
  2. Store policies and authorization data, called facts, in Oso Cloud
  3. Make API calls with our client SDKs from your app when you need to answer authorization questions, like can user X view Z resource? or what resources can user X edit?

​
Writing policies in Polar

Oso Cloud’s policy language, Polar, is designed for expressing arbitrarily complex and granular application authorization logic. Polar can express any model, including RBAC, ReBAC, ABAC, fine-grained authorization, organizational hierarchies, and more.

​
Data management

Facts are a prescriptive data model for authorization-relevant data. There are multiple ways to provide facts to Oso Cloud. Which one you choose depends on your use case and application architecture.
Data that is exclusively or extensively used for authorization, like users, roles, and permissions are best stored in Oso Cloud as facts. Oso Cloud provides a robust mechanism for synchronizing data stores and detecting drift with Oso Sync.
Oso Cloud supports centralizing your data, but doesn’t require it. [Local authorization] is our unique approach to minimizing data synchronization and data transfer. When you make a request to the Oso Cloud API, you receive back database logic that can be executed against your local data store to finish the authorization evaluation.
Oso Cloud also supports providing data at request time, called context facts. This is useful when you have data that is not used regularly for authorization, but is needed to evaluate the request.

​
Evaluating authorization requests

Oso Cloud can return booleans, a list of resources, a list of permissions, or even database logic that can be used to complete an authorization decision. It all depends on your application requirements.