“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. They looked for a service but couldn’t find one, so they were forced to build it themselves.

As they grew, they found themselves dedicating an entire feature team to building and maintaining their homegrown authorization service. That team had their hands full with a never-ending set of requirements, as their startup moved up-market and sold into larger organizations. On average, these SaaS startups had to rebuild authorization every 3-4 quarters - carrying a significant opportunity cost.

Gert and I are no strangers to Authorization: between us, we’ve built many Identity & Access Management (IAM) systems -- Active Directory, System.Identity, Azure Access Control Service, Azure Active Directory, and OpenStack Keystone, to name a few. When we took a fresh look at the IAM space in late 2020, we asked ourselves - why do we not yet have the “Stripe” for Authorization?

Could it be that every application wants to do authorization differently? This clearly wasn’t the case. Most engineering teams we talked to were working from the same set of patterns: RBAC and ABAC systems, with permission sets that are the cartesian product of the nouns and verbs in their domain model. Most of the authorization systems we encountered were highly duplicative.

When we surveyed the field of attempts at solving this problem, we realized that the only companies that could afford to do it right were large, sophisticated organizations like Google, Netflix, and Airbnb, who run these systems as an internal distributed service. This dovetailed with our own experience building IAM systems like Azure Active Directory. Because Authorization requires a sophisticated distributed systems architecture, it is difficult to get right.

Unlike authentication, which happens only once (at the beginning of a user session), authorization happens during the critical path of every application request. This means the latency budget for authorization has to be measured in a small number of milliseconds, and the availability of the service needs to be 100% - if you can’t reach the service (no matter how many 9’s it provides), your application can’t function.

This no longer sounds like Stripe. This sounds like a local library. And in fact, the only off-the-shelf solutions that developers can turn to today are libraries.

But that’s not what anyone means when they say “Authorization as a service”. Developers want a central control plane that manages all the artifacts that are involved in making an authorization decision: the authorization policy; user attributes, roles, and permissions; and the decision logs that stream out of the authorization service.

We all want to have our cake and eat it too: a platform service that is managed and delivered by a vendor, but has the real-time characteristics of a library.

That’s what we set out to do with Aserto: finally provide the missing piece in the developer API ecosystem, delivered with the right architecture. An authorization platform that:

• Runs in the same subnet / kubernetes pod as your application, and therefore provides 100% availability: if your pod is up, the authorizer sidecar is up
• Requires NO connectivity with the outside world when making an authorization decision
• Makes an authorization decision in milliseconds
• Manages authorization policy in a central repository, and transparently synchronizes policy changes to the edge
• Normalizes user attributes, roles, and permissions from a set of identity providers and directories, and transparently synchronizes those to the edge
• Aggregates all of the decision logs from the edge nodes, to provide a single auditable system view of every authorization decision your application has ever made

To fulfill our vision, we’re announcing our $5.1M Seed investment, led by Costanoa Ventures, with participation from Heavybit Industries, as well as a set of angel investors with deep experience in developer ecosystems, identity and security, and modern enterprise platforms. We couldn’t ask for a better or more supportive set of investors on this journey.

Over the last couple of months, we’ve had the privilege of working with a small number of design partners in our “alpha” phase. We are now expanding the aperture and looking forward to working with a larger set of partners as we continue to march towards our public beta. If you’re an early to mid-stage startup selling into the enterprise, join us.

Welcome to modern authorization.