Best Practices for Authorization Data

When integrating Oso Cloud into your application, you need to determine where and how to store your authorization data––i.e. the data that Oso evaluates when making authorization decisions.

Oso provides three approaches for managing authorization data:

• Centralized authorization data, which lets you store authorization data in Oso Cloud, where it's accessible to all clients.
• Local Authorization, which lets you use locally available data in a PostgreSQL database.
• Context facts, which lets you send authorization data along with requests to Oso Cloud.

Oso recommends the following best practices, particularly for microservice-oriented architectures:

• If the data can vary with metadata from the request (e.g. a request's locale, the wall-clock time), use context facts.

• If other services depend on the data for authorization decisions, synchronize it as centralized authorization data.

  Importantly, services can still use Local Authorization for requests that only depend on data available in their own databases, even if they also centralize data in Oso Cloud.

  For example, consider an application with two services: one for users and one for documents. The document service depends on the user service's data (e.g., role assignments) for authorization, which means that the user service's authorization-related data should be centralized. However, the user service can use Local Authorization for its own requests, such as letting users create other users.

• For authorization data describing relationships between resources (e.g. has_relation facts):

  • To maximize performance, use centralized authorization data.
  • To minimize the amount of data you synchronize, prefer using Local Authorization.

• For resource attributes (e.g., is_public(Document{"1"})):

  • If you're using centralized authorization data for the resource already (e.g. its has_relation facts), use centralized authorization data for the attributes, as well.
  • Otherwise, prefer using Local Authorization.

Note that in addition to this guidance, there are some additional considerations for using Local Authorization.

In cases where Local Authorization isn't preferable and context facts are inappropriate, use centralized authorization data.