Authorization as a Service

What is Authorization?

Authorization is how you control who can do what in your application. For instance, imagine we were building a new code repository hosting service called GitClub. The authorization system would make sure that only repository collaborators could push changes, and that only repository owners can invite new collaborators. Authorization is critical, but it’s also (usually) separate from the business logic of an app. If you mix authorization logic with your app’s logic, it can be hard to make changes to your app without touching authorization.

When Will You Need Authorization as a Separate Service?

No matter your architecture, you’ll need a way to coordinate your authorization between services while that authorization stays decoupled from your app code. In a monolithic app, you can decouple authorization from your app using an authorization library. In a simple microservice architecture, you can start by adding roles on a token to each request. This is what Carta did. However, these tokens can easily become too big to pass around, which means more often than not you’ll need a separate service for authorization (also what Carta did). Here's why:

  • You’ll need to share authorization data across services. This is critical when you need data from two sources to make an authorization decision. For instance, take the imaginary GitClub app from before. Now imagine we build a new service, GitClub Actions. To view an action, you might need to check both the permissions on the action itself and the repository that the action is associated with – but this data lives in two separate services.
  • Having a single authorization API makes development quicker and easier. There's no need to re-implement authorization in each service.
  • Using an authorization service means that making changes to your authorization logic  happens in only one place, which is quicker and less error-prone. This also makes it easier for different teams to agree on authorization models.

Who Has Built Their Own Authorization Service?

Some serious engineering teams: Google, Slack, Airbnb, Carta, and several others. For each of these companies, building an authorization service required at least a year of engineering work from a dedicated team.

Google needed a unified authorization system across Calendar, Cloud, Drive, and Youtube (and everything else). They chose to write an authorization service to make it easier for their apps to coordinate access control. Over several years, a dedicated team designed and built Zanzibar, a highly-available and scalable authorization service.

Slack needed a shared, modularized authorization service for their enterprise customers. Their team built a microservice that reads permissions from their monolith's data store. Their speed requirements mean that they cache their authorization data and accept some cases of stale permissions. It took a team of about ten engineers a year to design and build this service.

Airbnb found that they were duplicating authorization checks in each of their microservices. Over time, those authorization checks got out of sync and difficult to manage. They designed their own authorization service, Himeji, around a Google Zanzibar-like model. Building and scaling Himeji took them more than two years, and it continues to be supported by a full team of engineers.

Carta had the same problem—getting five different services to agree on authorization checks. They took a similar approach. It took their team about 9 months.

How Can You Build an Authorization Service?

Building an authorization service yourself is a difficult job, but it’s possible! Your team will have to write a service that:

  • Is at least as available as the rest of your stack—the authorization service is hit by nearly every other service.
  • Processes requests with low latency, usually to a target of below 50ms per query.
  • Stores your authorization data model. Usually, this means storing and modifying data like Roles or Relationships, at a minimum.
  • Stores entire authorization policies, and allow admins to modify those policies.
  • Can support the full breadth of authorization models while still returning queries—both yes/no and list endpoint queries—reliably fast.

If you'd like to take this path, our Authorization Academy is a series of technical guides on building application authorization. It covers authorization architecture in detail.

If you'd rather not commit the engineering time to build an authorization service yourself, you can use a pre-built service.

Authorization-as-a-Service Options

Zanzibar-based products

Google built Zanzibar to be a centralized database for storing relationship data, optimized for answering authorization questions. It uses a configuration language based on set rewriting as the main way of expressing authorization logic.

The main advantage is the data model—it’s highly performant for authorization, and can support some of the core use cases, like role-based access control (RBAC) and relationship-based access control (ReBAC).

There’s a learning curve to using Zanzibar-like systems. First, you need to remodel your data to conform to the right format. Next, you need to understand how to model your authorization using the language of relation tuples.

In practice, teams that have adopted Zanzibar (or similar) solutions end up needing to invest many additional months/years working with the application development teams to figure out how to integrate a solution. Because of that cost, Zanzibar is best for authorization across extremely high-scale applications—think authorizing between Gmail, Google Drive, and Google docs.

Authzed and Auth0’s Sandcastle are example Zanzibar-based managed services. SpiceDB and Ory Keto are open source binaries based on Zanzibar that you can run yourself.

OPA-based products

OPA (Open Policy Agent) is a policy engine built for controlling access to infrastructure. It uses its own language for writing policies, Rego. There’s a growing community around OPA, and the Rego language is very flexible. There’s some learning curve to Rego.

OPA is ideal for controlling infrastructure access, like managing who can created or delete Kubernetes objects, and when. However, OPA is not built for supporting large amounts of data as is common in application authorization. As such, it can be prohibitively slow when attempting to use with normal application workloads.

Some companies have built application authorization products on top of OPA, like Aserto and Permit.io.

Oso Cloud

Oso Cloud is a managed authorization-as-a-service. You use it to provide fine-grained access to resources in your app, to define deep permission hierarchies, and to share access control logic between multiple services in your backend.

You write policies in the Oso declarative authorization language, Polar, to describe who is allowed to do what in your app, e.g., an owner of a repo can edit the repo. You store your authorization data in Oso Cloud. Then whenever you need to authorize a request, you can check to see if it’s authorized and get back a yes or no response. Oso can also respond to more complex authorization questions, like returning a list of all authorized resources.

Oso is built for application authorization. It comes with built-in primitives for patterns like RBAC and ReBAC, and it is extensible for other use cases like attribute-based access control (ABAC). It is built using a best practices data model that makes authorization requests fast and ensures that you don’t need to make schema changes to make authorization changes. Oso Cloud is also deployed globally for high availability and low-latency.

Oso Cloud is not designed for infrastructure authorization or for embedded device use cases. It is not available for on-premise deployments at this time.

How to get started

If you want to try Oso's managed authorization-as-a-service, get started here. If you’d like to learn more about Oso Cloud or try it out, set up a 1x1 with our engineering team.

Get Started with Oso Cloud

Level up your authorization knowledge

Explore our docs

Access guides, example policies, and authorization best practies.
Read Oso docs

Read Authorization Academy

A series of technical guides for building application authorization.
See all chapters

Learn about Oso Cloud

Authorization for two services or thousands.
Dive into Oso Cloud