<aside> 💬 Schedule a 1x1 to go through this guide with an Oso engineer.
Oso Cloud is a simple way to store authorization data and use it for access decisions. You can use Oso Cloud to provide fine-grained access to resources in your app, to define deep permission hierarchies, and to share access control logic between services in your backend.
In addition to storing authorization data, Oso Cloud uses a policy file written in the declarative authorization language Polar. This allows you to write arbitrarily complex implications about your authorization data. Perhaps an
admin role at an organization always grants users
write access to resources that organization owns. You’ll write that logic as Polar code, and Oso Cloud will efficiently use those rules to make authorization decisions.
Inputs — what you’ll provide to Oso Cloud:
user X is an admin of organization Y,
document A belongs to folder B, etc). These are sent to Oso Cloud using the write APIs:
add_relation, etc. This data is persisted in Oso Cloud.
admins of organizations can edit documents owned by those organizations. The policy file is also persisted in Oso Cloud.
Outputs — what you’ll use Oso Cloud to do:
can user X edit document Y?
which documents can user X edit?
Oso Cloud (unlike the Oso open-source library) lives separately from your applications, and stores its own data:
An Oso Cloud server exposes three APIs: the write API which updates authorization data (or keep it in sync with your application), the check API which makes authorization decisions, and the policy API which updates your policy code.
This guide will walk you through deploying your first policy and making your first authorization checks with Oso Cloud. You’ll use the Oso Cloud CLI, which is a thin wrapper around the HTTP API.
First, install the Oso Cloud CLI (and make sure that
oso-cloud is in your system
$ curl [COMPANY].oso.run/install.sh | bash
Configure your Oso CLI to use your Oso Cloud server by setting the
OSO_URL environment variable: