Distributed Authorization

Authorization decisions require two things: logic and data. If you're interested in Authorization as a Service, it's probably because you're trying to solve a problem with your authorization logic:

It's intermingled with your application logic.
It's scattered across multiple services
Some of it's in application code, some of it's in SQL
It's hard to test
It's hard to debug

All of these problems can be solved by making your authorization logic explicit, which is something Authorization as a Service solutions do by centralizing your authorization logic in the service. In order to use that logic to render an authorization decision, today's Authorization as a Service products also require you to centralize your authorization data in the service.

Oso Cloud, by contrast, provides Distributed Authorization. With Distributed Authorization, you can centralize your authorization logic, but leave your application data in your local database. This lets you solve your existing problem - managing authorization logic, without creating a new problem - managing authorization data.

At first, this may sound like a subtle distinction. To illustrate it more clearly, it helps to understand the origins of the centralized approach to Authorization as a Service: Google Zanzibar.

Centralized Data: The Shadow of Google Zanzibar

In 2019, Google published their whitepaper on Zanzibar, their internal authorization service. Its key defining characteristic is centralization. All authorization logic and all authorization data at Google are stored in Zanzibar. In the time since that paper was published, it's inspired countless authorization implementations. As a result, every Authorization as a Service product today looks an awful lot like Zanzibar.

Model your authorization rules in the service.
Send your authorization-relevant data to the service.
Send authorization questions from your application to the service.
The service combines your logic and data to return a yes or no answer.

Centralized Authorization as a service: the service holds your authorization logic and data, and responds "yes" or "no" to authorization questions.

This sounds fine in bullet-point form, but that "send your authorization-relevant data to the service" item masks a lot of pain. Because that authorization-relevant data is also application data, you have to maintain two copies of it: one copy in your application, and another in the authorization service. Some of that data can be very large - say, all of the issues on all the repositories in an application like GitHub. Some of it changes frequently, like the jobs that are currently running against repositories in GitHub. Keeping all this data in sync, detecting and remediating drift, and ensuring consistency between your application and your authorization service is a huge hidden cost that many people don't consider when implementing authorization as a service.

Why Distributed Authorization?

With Distributed Authorization, you still centralize your authorization logic. This gives you all the benefits of making that logic explicit: you can reason about it, test it, debug it, and monitor it. You can also still use all of your application data to make authorization decisions. But, you don't have to send that application data to Oso Cloud. Instead, you can tell the Oso Cloud client in your application how to resolve authorization questions using local data. This allows you to use high-volume or transient data in authorization decisions without incurring the overhead of keeping that data consistent in two places.

To make this possible, we've enabled Oso Cloud to respond to authorization questions with a third answer: yes, if. When Oso Cloud detects that it needs local data to answer an authorization question, it returns a partially evaluated response to the client. This response includes information about which local data is still needed. The Oso Cloud client then queries your local application database to complete the response to the authorization question.

Distributed Authorization as a service: the service holds your authorization logic and shared data, and responds "yes, if" when it needs local data to finish answering an authorization question.

Filtering Lists

One area where this shines is filtering lists of authorized data. Suppose you have a version control application like GitHub. You have Organizations, which own Repositories, which in turn own Issues. If you want to generate a list of all the issues that a person has permission to view, and all of your data is centralized in your authorization service, then the operation looks like this:

Ask the service for a list of Issue IDs that the person can view.
Get back from the service the full list of IDs
Use the list of IDs to query your local database for Issue data

Centralized list filtering: the service returns the full list of IDs to the client. For users who belong to multiple organizations, or who belong to organizations with very active repositories, that list of Issues can get very long! It's not hard to envision situations where a user has access to hundreds or thousands of issues.

List Filtering with distributed data allows Oso Cloud to return a (much shorter) query filter to the client, which tells the client how to construct the full list from locally stored data. This is much less data being sent over the wire, and it allows you to filter and paginate the response using the tools you're already using to handle large sets of application data.

Distributed list filtering: the service returns a query filter to the client.

For a more full-fledged example of List Filtering with distributed data, check out our Ruby on Rails sample app (opens in a new tab)

Learn more

To learn more about how to use Distributed Authorization, read the following:

Deep Dive Tutorials