Comparison: Oso vs. Open Policy Agent (OPA)

Oso is an authorization library that includes a declarative policy language. OPA is an authorization product that includes a declarative policy language. Despite that, there are many significant differences between the two! Here's a comparison.

A few caveats:

1. We are experts in Oso, first and foremost.
2. We have plenty of respect for other technologies, OPA included.
3. Technology moves fast, and we'll do our best to keep this post current. But please note when this post was last published—both libraries may have changed.

Summary: Oso vs. OPA

The main differences between Oso and OPA are:

1. Enforcement (data layer, UI, etc.) - Oso provides APIs for enforcing authorization in your application, whereas this is currently out of scope for OPA.
2. Architecture - Oso is an embedded library with support for Python, Node.js, Go, Ruby, Java, and Rust. OPA is most commonly run as a binary in a separate process (though it can also be used as a Go library). These differences have implications for the work that you'll do to ensure Oso or OPA has everything it needs to make an authorization decision.
3. Modeling - Oso provides abstractions for the most common application authorization models (like role-based or attribute-based authorization), and is backed by a declarative policy language called Polar. OPA also provides a policy language called Rego.

...All of which in turn are closely tied to

1. Use cases - Oso is focused only on application authorization. OPA is a policy engine and has focused a lot of development effort on Kubernetes infrastructure authorization.
2. Company & Source Access - Oso was founded in 2018 and the project was open-sourced in 2020. Styra (the company behind OPA) was founded in 2016 and open-sourced OPA in the same year.

Enforcement (data layer, UI, etc.)

Enforcement is what your application actually does with an authorization decision. Once your app has decided to deny access, for instance, how does it show that to the user?

Oso provides APIs for enforcing authorization at multiple layers of the app, including filtering data at the data access layer and checking permissions in the client-facing user interface.

Here's what it looks like:

Data filtering in Oso works by using our declarative policy language Polar to evaluate policies and return a set of filters. The same approach works for fetching all the permissions a user has on a resource or for all the users that can read a resource.

OPA is a policy engine whose primary responsibility is to make policy decisions. OPA intentionally decouples authorization from the application. This means that it doesn't provide enforcement integration with the application.

Architecture: Library vs. Binary

Oso is an embedded library with support for Python, Node.js, Go, Ruby, Java, and Rust. OPA is most commonly run as a binary (though it can also be used as a Go library).

This can affect your deployment process. Consider how your deployment process supports importing a native library versus running a daemon.

Architecture: The Policy's Access to Your Data

The two pieces that make up an authorization decision are logic and data.

1. Logic: rules and conditions that govern access (e.g., admins can update posts).
2. Data: record-level information about application objects (e.g., whether this user is an admin).

Whether you use Oso or OPA, you need both logic and data in order to make a single decision. Both Oso and OPA push you as a developer to separate logic from data by asking you to represent your authorization logic in a separate policy.

The question you're concerned with is: how does the policy get access to the data it needs to make a decision at request time?

Using Oso, you write policies over your application data. Because the library is embedded in your app, it always has access to the data it needs to make authorization decisions. Your policy can access properties and call methods on your objects.

Using OPA, your policies are decoupled from your application code and data. Usually, you'll run OPA as a daemon. When doing this, you need to find a way to get the relevant data to OPA so it can make authorization decisions. OPA provides several ways to do this, each with different pros and cons — see OPA docs for a complete description.

Modeling (RBAC, ReBAC, etc.)

Oso provides abstractions for the most common application authorization models. We include these abstractions as primitives built into the language—for roles, relationships, and other common patterns. For instance, using a resource block, you can write "update" if "admin" on "parent_org" to say: a user can update [a post] if they are an admin on the parent organization [of the post]. We provide the flexibility of the Polar language for when those abstractions don't suit your use case.

In OPA's case, you write policies using Rego, a Datalog-inspired language. The OPA docs include basic guides on implementing role-based access control (RBAC) and attributed-based access control (ABAC) guides, but these are not included as features of the product.

Use Cases

These differences between Oso and OPA reflect different areas of strength and focus.

Oso is squarely focused on application authorization. In addition to building the Oso product, for instance, we have also invested heavily in Authorization Academy, a series of technical guides on building application authorization. We drive all our roadmap decisions on how our customers are using Oso for application authorization and how we can make the experience of building for this use case great.

By comparison, OPA is a policy engine. Their main focus for the last few years has been authorization for Kubernetes infrastructure. They provide built-ins for enforcing policies on Kubernetes objects.

Community & Company

Oso was founded in 2018, and the project was open-sourced in 2020. Developers at startups like Fiddler and Sesh use Oso in production, as well as larger companies like Intercom, Wayfair and Visa. At the time of this writing, Oso has 1.6K GitHub stars.

By comparison, Styra (the company behind OPA) has been around for longer, and so has the OPA project. Several development teams have spoken publicly about their usage of OPA, including Bisnode, Chef, and Netflix. Styra was founded in 2016 and open-sourced OPA in the same year. At the time of this writing, OPA has 5.7K GitHub stars.

Both Oso and OPA are pre-1.0.

Learn more about authorization best practices

If you want to learn more about authorization best practices, here are some resources you might find useful:

• Authorization Academy, a series of technical guides on building application authorization (not specific to Oso).
• Why Authorization is Hard, a long-form technical post from cofounder/CTO Sam on the technical problems in the domain.
• The Oso Community Slack, a good place to ask questions. There is at least 1 engineer in there during US business hours, plus there are hundreds of other developers in there working on application authorization.