Authorization as a Service

I’ve lost count of how many teams I’ve seen build and rebuild their permission systems, each time thinking, ”This one will scale”. But after cleaning up enough tangled rule logic, one thing is crystal clear: Authorization isn’t just another feature. It’s infrastructure. And just like any infrastructure, it demands deeply intentional and careful design.

At its core, authorization is about deciding which users (or services) can perform actions on which resources. Implementing it in an application involves defining roles, managing permissions, and structuring relationships. Authorization as a service externalizes this logic for you, centralizing it into its own dedicated system.

This article will draw on my years of experience in this domain to explain how external authorization services work. We will also discuss why you need a separate layer for authorization and the available tools for implementing it. Let’s get started.

Authorization vs. Authorization as a Service

Authorization is deceptively simple at first. Early versions of an app can usually get away with a few hardcoded roles and boolean flags.

But as applications evolve, more services get added, more teams contribute to the codebase, and more user types appear. The original role/boolean authorization model can no longer fit the needs of a fully distributed system. New challenges include:

• Per-resource permissions: User A should be able to update their own post at /posts/123, but should receive a 403 Forbidden (denying access) if they try to update User B’s post at /posts/456.
• Multi-tenancy: A user from Organization A querying /customers should only see records where org_id = A.
• Tiered access checks: A user with the developer role should be able to access the /logs and /debug endpoints, while a user with the viewer role should be restricted to read-only dashboards, like /metrics.
• Service-to-service communication: When the billing service sends a request to /users/:id/usage, it should only succeed if it includes an access token with the billing:read_usage permission. Otherwise, the request should be denied.

And to make matters worse, this authorization logic is often duplicated or inconsistently implemented across multiple services. In a microservices architecture, this kind of fragmentation becomes a breeding ground for bugs (and lots of painful debugging sessions).

Together, these challenges laid the groundwork for a new approach: Authorization as a service.

What Is Authorization as a Service?

Authorization as a service refers to using a third-party service to handle authorization requirements in your app. It moves your access logic into its own layer and becomes the single source of truth for permissions across your services. In every system I’ve seen succeed, centralized authorization has been the thread holding everything together.

AaaS (Authorization as a service) lets existing systems communicate with it via APIs such as can(user, action, resource). Behind the scenes, the service evaluates the request using policy definitions and user data. The underlying authorization logic is hidden and the app gets a simple yes or no. This design has several key advantages:

1. Policies can be updated (and version controlled) without touching the business logic.
2. Access rules can be tested in isolation.
3. Authorization decisions can be cached directly within the auth layer.

This table sums up the differences between traditional authorization and Authorization as a Service.

Benefits of Decoupled Authorization

Regardless of your architecture, you’ll need a way to coordinate authorization in a way that keeps it separate from your core business logic. Here’s why.

Cleaner Code

Centralization eliminates redundancy. In traditional systems, authorization logic is spread across frontend clients, backend services, and API gateways. It’s a nightmare to maintain. With a dedicated layer, you’re following one of the golden rules of scalable systems: don’t solve the same problem twice. When auth lives in one place, your system becomes simpler to maintain.

<aside>💡

Expert Insight: I treat authorization policies the same way I treat application code. Everything goes through version control. It gives me a clear audit trail, safer rollouts, and peace of mind knowing that I can revert instantly if something breaks.

</aside>

Security

Multiple implementations means more code. More code means more potential vulnerabilities. With everything consolidated together, you can run static analysis on your access control mechanisms and build targeted tests to reach full coverage across all user, resource, and action combinations.

<aside>💡

Expert Insight: Another convenience for AaaS solutions is that they’re built with customer security and compliance standards in mind (like SOC 2 and HIPAA), so “enterprise-level” checks are already done for you.

</aside>

Faster Team Iteration

When authorization is directly embedded into the application code, every policy change means touching business logic, writing tests, waiting for reviews, and triggering a full redeploy. But when separated, developers (or even product managers using a user‑friendly interface) can manage service/user permissions without slowing down the release cycle.

Scales with You

When applications evolve, so must authorization. You might start with Role Based Access Control (RBAC), but eventually need Attribute Based Access Control (ABAC) or Relationship Based Access Control (ReBAC). If your authorization logic is scattered, adapting becomes painful. A centralized location gives you the flexibility to update policies independently without disrupting the rest of the system.

<aside>💡

Expert Insight: Simplicity scales. Making your policies more complex than needed can turn your access model into “swiss cheese”, full of gaps and edge cases that are easy to overlook.

</aside>

Who’s Built Their Own Authorization Service?

Organizations typically take one of two paths: they either adopt a managed authorization solution or commit to building their own. When teams build in-house, it’s usually a sign of scale or the need for tighter control. Here are a few examples:

• Google needed a global authorization system to manage permissions across Calendar, Cloud, Drive, Youtube, and everything else. Over several years, a dedicated team designed and built Zanzibar, a highly-available service that can handle trillions of access control lists and millions of authorization requests per second.
• 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 solution took a team of about ten engineers a year to design and build.

• Airbnb found that they were duplicating authorization checks in each of their microservices. Their solution was Himeji, which makes use of a sharded in-memory cache. It took Airbnb more than two years to build and still continues to be supported by a full team of engineers.
• Carta had the same problem—getting five different services to agree on fine grained authorization checks. They took a similar approach, inspired by Zanzibar and took about 9 months to build and deploy their service.

Can You Build an Authorization Service Yourself?

Yes, it’s absolutely possible. I’ve been a part of teams that built their own authorization service from scratch. But I can tell you firsthand: it’s far from easy.

Your team will have to write a service that:

• Is at least as available as the rest of your stack—the auth service is hit by nearly every other service.
• Processes service authorization requests with low latency, usually targeting below 50 ms per query (or even less for high‑performance apps).
• Stores your authorization data model (roles, relationships, attributes).
• Stores entire authorization policies and allows admins to modify them.
• Supports the full breadth of authorization patterns while reliably returning both yes/no and list‑style queries.

If you’re serious about building your own system to implement authorization, check out Oso’s Authorization Academy for deep dives on policy management, data modeling, and access patterns.

For teams with less bandwidth or those who want to stay focused on product features over infrastructure, authorization as a service is usually the way to go.

Choosing the Right Authorization-as-a-Service Tool

If you’re trying to decide between Authorization as a Service tools, you can bucket them into three categories: Zanzibar-based, OPA-based, and other managed services. Here’s how I think of the tradeoffs.

Zanzibar-based Products

Zanzibar was built by Google to centralize authorization across its products. It relies on a configuration language based on set rewriting as the main driver of expressing authorization logic.

[H4] Advantages

• Zanzibar’s authorization model is highly performant (can handle millions of fine grained authorization checks per second with less than 10 ms latency and greater than 99.999% availability).
• It can support some (but not all) core authorization use cases, like role-based access control (RBAC) and relationship-based access control (ReBAC).

[H4] Disadvantages

• You must centralize authorization data in Zanzibar, which requires building custom sync and reconciliation layers to keep everything consistent.
• It only partially supports list filtering.
• It typically requires a large-scale migration, unlike other solutions that support a gradual rollout.

[H4] When should you use Zanzibar?

Because of its high engineering cost, Zanzibar is most appropriate for large-scale applications (think along the lines of having to manage fine grained permissions across Gmail, Drive, Docs, and the rest of the Google ecosystem).

[H4] Tools that offer Zanzibar-style Authorization

Managed Zanzibar-based services include AuthZed and Auth0’s Sandcastle, while open source alternatives like SpiceDB and Ory Keto let you deploy the model yourself.

OPA-based Products

OPA (Open Policy Agent) is a policy engine built for controlling access to infrastructure. It defines policies using its own declarative programming language called Rego.

[H4] Advantages

• Rego gives you a lot of control and is flexible enough to model most access rules.
• OPA has an active community and well‑maintained documentation.

[H4] Disadvantages

• Rego is built for manipulating data, not modeling authorization. If you want to model things like RBAC and ReBAC, you have to express them as transformations over structured data.
• OPA can be too slow for real‑time application workloads where low latency is important.

[H4] When should you use OPA?

OPA works well for infrastructure use cases such as managing access for Kubernetes resources.

[H4] Tools that offer OPA-style Authorization

Companies that have built application authorization products on top of OPA include Aserto and Permit.io.

Oso Cloud

Oso Cloud is a fully managed Authorization as a Service. It provides abstractions for building and iterating on authorization in your existing systems and has been the backbone for hundreds of engineering teams over the years.

[H4] Advantages

• Oso is designed specifically for application authorization, with built‑in support for modern authorization  models like ABAC, RBAC, and ReBAC.
• Its data model enables fast authorization checks and its service is globally deployed for high availability and low latency (<10 ms end‑to‑end).
• Oso can also respond to more complex authorization queries, like returning a list of all authorized resources.

[H4] Disadvantages

• Oso is not designed for infrastructure authorization like OPA‑based products.
• Oso can’t be used for embedded device use cases.
• It is currently offered as a managed service only and does not support live on‑premises deployment, thoughit does provide an on-premises fallback capability.

[H4] When should you use Oso Cloud?

Oso Cloud is well suited for application‑layer and service authorization in distributed architectures, including support for models like ABAC, RBAC, ReBAC, or a combination of these.

Conclusion

Through my work with distributed systems, I’ve come to see authorization for what it really is: an architectural layer. As applications scale, so does the complexity of access control. What starts as a handful of hardcoded access control checks can quickly turn into a web of duplicated logic spread across services.

The value of Authorization as a Service goes beyond convenience. It’s a separation of concerns. It lets you isolate your authorization process, test it independently, and evolve your authorization data schema without having to touch your application code.

Not every team needs to outsource authorization from day one. But if your system is growing and you’re starting to notice inconsistent checks, duplicated logic, or developers spending too much time on auth code, it may be worth rethinking your strategy.

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 1×1 with our engineering team.

FAQ

What’s the difference between authentication and authorization?

Authentication verifies who you are (e.g. logging in), while authorization determines what you’re allowed to do (e.g. can this user access this resource?). This article focuses on the latter.

When should I start thinking about Authorization as a Service?

If you’re seeing authorization logic duplicated across services, or policy changes are slowing down deploys, it’s time to consider an authorization service for your app’s permission management. You don’t need to start there, but you should plan for it before things get messy.

Can I build my own authorization service?

Yes—but it’s a major engineering investment. You’ll need to build a low‑latency, highly available service, model and store roles and relationships, version policies, and support both yes/no and list-style queries. Many large teams (like Google, Slack, Airbnb) have done it—but it took months or years and dedicated teams. It may be worth comparing the tradeoffs between this and leveraging existing third party services.

How does Authorization as a Service work?

Your app makes API calls like can(user, action, resource) to a central service. That service uses policy logic and contextual data (roles, attributes, relationships) to return a decision. It’s fast, consistent, and easy to test independently.

What’s the benefit of separating authorization into its own layer?

Separation with authorization systems means you can version and test complex policies without touching the codebase and application logic. It also helps eliminate duplicated checks, centralize audits, and evolve your access model (e.g. moving from RBAC to ReBAC) without introducing inconsistencies.

What’s the difference between RBAC, ABAC, and ReBAC?

• Role Based Access Control (RBAC): Permissions are granted based on roles (e.g., admin, editor).
• Attribute Based Access Control (ABAC): Permissions depend on user or resource attributes (e.g., region = “EU”).
• Relationship Based Access Control (ReBAC): Permissions depend on relationships between entities (e.g., user owns document).

For more information on access control mechanisms, check out this blog.

How does Oso Cloud compare to Zanzibar-based and Opa-based Products?

Oso Cloud delivers Zanzibar-style authorization as a fully managed service. Unlike Zanzibar, which requires apps to conform to its data model and Opa that is built for manipulating data, Oso works with your existing systems, whether that’s RBAC, ABAC, ReBAC, or something else.

‍