Sign in

A Docker-inspired workflow for OPA policies

Lottie the axolotl :)

A brief history

When we first started using OPA, we were impressed with how flexible it is as a general-purpose decision engine. We were familiar with using it for infrastructure scenarios (like k8s admission control), but thought we could extend its use to application and API authorization scenarios.

One thing we missed, though…

Building awesome apps with OPA just got easier.

OPA and the OPA logo design are registered trademarks of the Cloud Native Computing Foundation.

At Aserto, we use OPA heavily in our authorization API as the underlying decision engine. We’ve been looking for a simple way to compose our solution over the OPA engine, and the OPA SDK provided us with a good starting point.

We had some additional requirements, though: we wanted to

Using your system to build your system, or more colloquially, “eating your own dogfood”, is an age-old practice for validating that a system is capable of supporting a serious use-case, and that its designers would trust their system enough to bet their entire endeavor on it.

So it’s not exactly…

math equations

As we all know, software versioning is super important. At Aserto, we mostly deal with go binaries and container images. We knew that we wanted to use semver as a strategy from the start, but we couldn’t find a solution with the right features for us. …

Aserto uses the Open Policy Agent (OPA) as the decision engine for evaluating authorization decisions. Rego is the policy language for defining rules that are evaluated by the OPA engine.

For engineers that are used to imperative languages like Javascript or Python, Rego can look a bit foreign. …

Vlad Iovanov

In the past we’ve explained how Scopes are NOT Permissions. I’d like to give you a real-world example of why this matters, and how things can be better.

One feature that we have over at Aserto is the ability to integrate with Github: we help you get started…

access denied

[This article first appeared on The New Stack]

Most software developers think of Authentication as a solved problem. We can rely on a mature set of standards, such as OAuth2, OIDC, SAML, and JWT, and libraries in every language that make it easy to implement authentication. …

“There’s a developer API for that.” Over the last ten years, we’ve seen this answer become ubiquitous for almost any functionality that developers would rather integrate than build from scratch: sending text messages (Twilio), sending bulk email (SendGrid), collecting payments (Stripe), authenticating users (Auth0)… with one glaring exception: Authorization.


Photo by Jan Antonin Kolar on Unsplash

We’ve talked to countless developers about how they’ve built and evolved their authorization systems over time. One common regret that keeps coming up involves getting burned by using OAuth2 scopes in a JWT as the sole basis for making authorization decisions.

OAuth2 scopes were never intended to be an authorization…

salt and pepper shakers contrast authentication and authorization
Photo by Lachlan on Unsplash

Authentication is proving who you are to an application or a system. Authorization is the system determining whether you’re allowed to carry out an operation on a resource.

In 2021, authentication is a solved problem. But authorization remains a far bigger problem, and is far from solved.


Why do so…


Welcome to modern authorization.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store