Authorization Data
To make authorization decisions, Oso uses two components:
- Your environment's policy, which describes the logic you want to use
- Authorization data, which describes your application's current state
When choosing where and how to manage your authorization data, Oso offers the following options:
Authorization data | Description |
---|---|
Local authorization | Oso lets you describe how facts in your policy are represented in your local database, and then lets you perform the final authorization steps locally. |
Centralized in Oso | Each Oso Cloud environment provides a database in which you may store authorization data. |
Context facts | Authorization requests let you provide additional facts, known as context facts. |
When to use each type of authorization data
If possible, Oso suggests using local authorization. However, the following are common exceptions.
Centralized in Oso
Centralized data in Oso when:
-
Services that rely on this data to make authorization decisions cannot query the database directly with local authorization.
For example, this is common for services that manage users, especially in microservice-oriented architectures.
This also occurs if you're using a database that isn't compatible with local authorization.
-
If you don't want to provide the service access to the database containing the authorization data.
-
Increasing the load on the database containing the authorization data poses a problem. For example, making authorization decisions within the database requires expensive joins for tables you don't want to index.
Context facts
Use context facts for authorization data that can only be determined by the requestor's environment.