Authorization as a Service

What is Authorization as a Service?

Authorization is how you control who can do what in your application. Authorization as a service means using a third-party service to handle authorization in your app. Using an authorization service can make your app more resilient and easy to deploy.

Why 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. But in apps with many services, you’ll need a separate service for authorization. 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.
• 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?

• Google needed a unified authorization system across Calendar, Cloud, Drive, and Youtube (and everything else). 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. 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. Building and scaling their authorization service, 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 to build and deploy their service.

Can You Build an Authorization Service Yourself?

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.

Advantages to Zanzibar:

• The data model is highly performant for authorization.
• It can support some (but not all) core authorization use cases, like role-based access control (RBAC) and relationship-based access control (ReBAC).

Disadvantages to Zanzibar:

• Using Zanzibar requires a huge engineering effort. Teams that have adopted Zanzibar (or similar) solutions end up needing to invest many additional months or years working with the application development teams.
• You’ll need to remodel your data to conform to Zanzibar’s format.
• You’ll need to learn how to model your authorization using Zanzibar’s language of relation tuples.

When should you use Zanzibar?

• Because of its high engineering 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.

Advantages to OPA:

• The Rego language is very flexible.
• OPA has a growing community and good documentation.

Disadvantages to OPA:

• There’s some learning curve to Rego.
• OPA can be prohibitively slow when attempting to use with normal application workloads.

When should you use OPA?

• When controlling infrastructure access, like managing who can created or delete Kubernetes objects.

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

Oso Cloud

Oso Cloud is authorization-as-a-service. It provides abstractions for building and iterating on authorization in your application – based on years of work with hundreds of engineering teams.

Advantages to Oso Cloud

• Oso is purpose-built for application authorization, and so comes with built-in primitives for patterns like RBAC and ReBAC.
• Oso Cloud is extensible for other use cases like attribute-based access control (ABAC).
• Oso Cloud is built using a data model that makes authorization requests fast and ensures that you don’t need to make schema changes to make authorization changes. It’s deployed globally for high availability and low latency.
• Oso Cloud can also respond to more complex authorization queries, like returning a list of all authorized resources.

Disadvantages to Oso Cloud:

• Oso Cloud is not designed for infrastructure authorization
• Oso can’t be used for embedded device use cases.
• It is not available for on-premise deployments at this time.

When should you use Oso Cloud?

• For all application authorization.

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.

‍