Authorization determines which users can perform actions on which resources. Implementing authorization within an application requires defining roles, permissions, and relationships while ensuring consistency across distributed services. As applications grow, managing authorization internally increases complexity, introduces duplication, and requires ongoing maintenance.
Authorization as a Service externalizes this logic, providing a centralized system for evaluating access control decisions. This article examines how external authorization services work, their integration patterns, and the available tools for implementing them.
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.
Authorization vs. Authorization as a Service
Both traditional authorization and Authorization as a Service determine access control within an application, but their implementation and management differ significantly. The table below outlines these differences, showing how externalizing authorization can centralize policy management, reduce duplication, and support complex access control models.
Traditional authorization works for small, monolithic applications with static access rules, where permissions rarely change and can be managed within the application code. However, as systems grow into distributed architectures or microservices, managing authorization across multiple services increases complexity, requires duplication, and makes consistency harder to enforce. An external authorization service centralizes policy management, eliminating the need to embed and update access control logic across services while enabling dynamic, fine-grained permissions that adapt to changing requirements.
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:
a. You’ll need to share authorization data across services. This is critical when you need data from two sources to make an authorization decision.
b. Having a single authorization API makes development quicker and easier. There's no need to re-implement authorization in each service.
c. 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?
Let’s look at how companies like Google, Slack, Airbnb and Carta have tackled the challenges of building their own Authorization services.
a. 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.
b. 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.
c. 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.
d. 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:
a. Is at least as available as the rest of your stack—the authorization service is hit by nearly every other service.
b. Processes requests with low latency, usually to a target of below 50ms per query.
c. Stores your authorization data model. Usually, this means storing and modifying data like Roles or Relationships, at a minimum.
d. Stores entire authorization policies, and allows admins to modify those policies.
e. 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 service 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:
a. The data model is highly performant for authorization.
b. 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:
a. You must centralize all authorization-relevant data in Zanzibar, which requires setting up sync and reconciliation infrastructure.
b. Only partial support for list filtering use cases.
c. Typically requires large migration vs. ability to adopt incrementally.
When should you use Zanzibar?
a. 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:
a. The Rego language is very flexible.
b. OPA has a growing community and good documentation.
Disadvantages to OPA:
a. Rego is built for manipulating data, not modeling authorization. If you want to model things like RBAC and ReBAC, you have to write them in terms of transformations of structured data.
b. OPA can be prohibitively slow when attempting to use with normal application workloads.
When should you use OPA?
a. 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:
a. Oso is purpose-built for application authorization, and so comes with built-in primitives for patterns like RBAC and ReBAC.
b. Oso Cloud is extensible for other use cases like attribute-based access control (ABAC).
c. 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.
d. Oso Cloud can also respond to more complex authorization queries, like returning a list of all authorized resources.
Disadvantages to Oso Cloud:
a. Oso Cloud is not designed for infrastructure authorization
b. Oso can’t be used for embedded device use cases.
c. It is not available for on-premises deployments at this time.
When should you use Oso Cloud?
a. 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.
