Authentication is "solved"

The authentication world has mature specifications that are universally adopted, such as OAuth2 and OpenID Connect. This has helped the industry solve "single sign-on for the web".

Authorization is next

The authorization world has lagged behind. Today, each application has its own way of assigning permissions to users, what we call an "N * M problem".

But help is one the way! OpenID AuthZEN aims to become the "OpenID Connect of authorization", and has just entered the review phase for the first Implementer's Draft of the Authorization API version 1.0.

Having served as co-chair of the WG and co-editor of the spec, this means a lot to us at Aserto. Why?

Why standardize authorization?

Standards efforts are multi-year affairs, so we don't take them lightly. Standardizing a developer technology needs three things to succeed:

• It addresses a significant pain point.
• Competing technology providers find areas where standardization doesn't erode differentiation, but accelerates adoption.
• It provides significant benefits to consumers and end-users of the technology, which drives adoption.

ODBC

Early in my career, around 1993, I witnessed this first hand with Open Database Connectivity, or ODBC. Consumers wanted data-centric applications (Excel, Access, Visual Basic, Powerbuilder, and countless more) to be able to talk to a bunch of data sources (Oracle, Sybase, SQL Server, DB2, Informix, and many others).

This is what we call an "N * M" problem: N applications need to build connectors to M data sources. Wasteful and expensive.

ODBC addressed this challenge by defining a universal data access API, which database vendors could implement, and applications could consume, transforming it into an "N + M" problem. All of the sudden, any data application could immediately talk to a whole bunch of data sources simply by being a consumer of ODBC.

My startup, NEON Systems, bet on this standard and rode its success by integrating data-centric applications with a wide variety of enterprise data sources. NEON was so successful it went public in 1999.

Open ID Connect

Two decades after ODBC, OpenID Connect (OIDC) became a standard that solved a similar problem. N SaaS applications needed to integrate with M corporate identity providers. By adopting the OIDC protocol, each SaaS app allows its users to sign-in with their corporate identity provider (Okta, Azure AD, Google Workspace, Ping ID, etc).

Admins no longer have to worry about corporate users creating their own logins on each SaaS application - they can use a single corporate login across all these applications. Onboarding and offboarding become a breeze!

At Microsoft, our vision for this started with SAML, WS-Security, and WS-Federation in the early 2000's, but it wasn't until 2013 that OIDC reached its tipping point. The journey took a while, but the result has been nothing short of transformational.

Open ID AuthZEN

Fast forward a decade to 2024: the same "N * M" problem exists in the authorization space. Every corporate application has its own way of assigning permissions to users. And the solution is similar to how applications have externalized authentication to an OIDC-compliant IDP: externalizing authorization to an AuthZEN-compliant Policy Decision Point (PDP).

Applications that do this not only save a bunch of time and effort rolling out their own bespoke authorization. They also allow IT administrators to enforce common policies across applications, ensure compliance across applications, and answer questions like "which users have access to which resources" across applications.

While authorization vendors want to differentiate on expressing policies, ensuring compliance, facilitating forensics, and managing authorization at scale, none of us really care about what the authorization API actually looks like. We all have similar APIs that are arbitrarily different, and they are not a real source of differentiation.

Standardizing the way a policy enforcement point (PEP) such as an application or API gateway calls an authorization platform (PDP) greatly reduces the friction of integrating the PEP with a wide variety of authorization solutions. It helps everyone:

• Applications and API gateways can integrate with a bunch of externalized authorization systems using a single API, instead of creating bespoke integrations with each.
• Authorization platforms become relevant to a broader set of applications and other policy enforcement points.
• IT Administrators have a single "Authorization control plane" to manage policies and entitlements, and answer questions such as "what resources does this user have access to".

What does this milestone mean?

So standardizing authorization is important. Why celebrate this milestone?

We started the OpenID AuthZEN WG in late October 2023. In one short year, we've been able to define a number of iterations of our first spec, the PEP-PDP API. We now have 13 interoperable implementations of a preview version of this spec.

We've learned quite a bit from the interop events we conducted at Identiverse 2024 and EIC 2024, and now have a candidate Implementer's Draft.

This milestone means that vendors can safely incorporate AuthZEN into their products, without worrying that the spec will "move under them". This also means that Policy Enforcement Points, such as API Gateways, SaaS applications, and identity providers can start calling out to AuthZEN PDPs to make authorization decisions.

What's next?

The review and voting period extends through November 9, 2024. At that point, we will have a formal Implementer's Draft.

Aserto is committed to incorporating AuthZEN in a first-class way into our authorization engine, Topaz, as well as our commercial products.

In addition, we're looking forward to working with the community to create developer SDKs for a wide variety of languages, and working with API gateway vendors to make it trivial to call an AuthZEN-compliant PDP from a request filter.

The next AuthZEN interop event is at Authenticate 2024 on October 15, 2024. We plan on testing the next iteration of the spec, which defines how to send multiple evaluations in a single request, facilitating scenarios such as turning on and off features in a web or native UI based on a user's permissions.

Future work

We have lofty goals for AuthZEN. We will define a search API which standardizes answering questions like "which resources does this user have access to", and "which users can access this resource".

We also plan on defining ways in which upstream data sources can send data updates to policy decision points and policy information points, so that PDPs can have the latest user, group, and relationship information when evaluating access decisions.

Learn more here

Check out Aserto's AuthZEN page for more resources about AuthZEN and how Aserto is involved. And if you're interested in influence the standard, join us at the OpenID AuthZEN working group!