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 with policy-as-code by creating policy repos for you based on our policy templates, complete with Github Actions that provide a CI/CD experience for policies.

Github’s authorization model

Part of this integration is authentication and authorization at the Github API level. We do it as documented: we take the user through an OAuth Application…

access denied
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. Developer APIs from vendors such as Auth0, Okta, and others make this even easier.

What about Authorization? Just like authentication, every B2B SaaS application requires an authorization system to enforce permissions that are granted to different tiers of users. But compared to authentication, authorization is a harder problem and is far from solved.

Developers want it


“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.

In late 2020, Gert and I set out to find out why. Out of 80 conversations we had with CTOs and VPEs of early- to mid-stage SaaS startups, nearly every single one of them said they’d rather integrate a service than build from scratch. …

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 mechanism, and indeed are a really bad idea when used as a substitute for a real authorization architecture. So how has this anti-pattern emerged?

Starting with authentication

When developers build a new application, one of the first things they need to implement is a login system. Thanks to standards like OAuth2 and OpenID…

salt and pepper shakers contrast authentication and 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 many people think of authentication and authorization as more or less the same thing — “auth”? Historically, there was only one place to log in — your operating system. …

Image credit: Takahiro Sakamoto on Unsplash

[This article first appeared on The New Stack]

How many times have you or your teams (re)built an authorization system? During the time I was the CPO at Puppet, we built (or rebuilt) authorization systems at least three times across our product portfolio. We did it not because it was a unique source of differentiation, but because our customers needed to integrate our products with the identity and access systems and processes they already had. It’s the “cost of doing business” for having an enterprise-grade SaaS product. …

Photo by Alex on Unsplash

Over the last decade, while working at Microsoft, HP, Puppet, Splunk, and Hulu, I worked on many projects related to the adoption or migration towards (cloud-native) service architectures. One recurring anti-pattern we struggled with were services with deeply embedded authorization logic, unable to evolve quickly enough to meet the changing business, scale, and technological requirements.

Trying to address these challenges, I often faced the same common pain points:

  • Each service has similar logic to ensure that calls to resources were only made after passing authorization checks. …

broken lock
broken lock
Photo by iMattSmart on Unsplash

With last year’s widespread shift to remote work, IT and security teams saw their challenges with identity and access control magnified many times over, making it clear that existing perimeter-based access control strategies are entirely insufficient for the modern world.

According to IDG and CISO’s Security Priorities Report, 32% of the organizations they talk to have earmarked new investments into modern authentication, authorization policies, and role-based access control, and nearly 70% are currently piloting Zero Trust programs in production or evaluating them. Whether or not we return to work soon, it’s clear that perimeter-based access control strategies are dead.



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