Looking into AuthZEN, a standard specification for authorisation

Introduction

At a session at KubeCon + CloudNativeCon Japan 2026, I heard the name AuthZEN for the first time. It was described as a specification that standardises authorisation, but I couldn’t get the full picture on the spot, so I went through the OpenID Foundation’s specification and the related announcements to sort it out for myself.

I have only just started learning about this area, so this article is less an explanation of facts and more a record of “here is how I understood it after looking into it”. Where my understanding turns out to be wrong, I intend to correct it as I verify things by actually running them. I plan to write separate articles for hands-on verification; this one stops at organising what the specification is and where it currently stands.

What AuthZEN is

The first thing I learnt is that AuthZEN is not the name of a single specification but the name of the OpenID Foundation’s AuthZEN Working Group and the family of specifications it produces. The central one is Authorization API 1.0, which defines the API an application uses to ask an authorisation engine “may this user perform this operation?”.

The specification assumes an architecture that separates making authorisation decisions from applying them. The side that makes the decision is the Policy Decision Point (PDP), and the side that requests a decision from within the application and applies the result is the Policy Enforcement Point (PEP). What the Authorization API standardises is only the communication between the PEP and the PDP. The policy language and the PDP’s internals are out of scope, and as I describe later, this appears to be a deliberate trade-off.

The problem it tries to solve

Pulling authorisation decisions out of application code and moving them into a dedicated engine is an approach that has long been recommended. Authorisation logic embedded across the codebase as if statements means rewriting the whole application every time the permission rules change, and it also makes it hard to audit from the outside who can currently access what. Policy engines such as OPA (Open Policy Agent) and Cedar are used as part of this same movement.

However, there was no standard for the communication between the engine (the PDP) and the application (the PEP), and every engine kept using its own proprietary API. With N applications and M engines you end up building N×M integrations, and switching engines means rewriting every call site on the application side.

AuthZEN tries to unify this communication between PEP and PDP into a single standard API. The application only needs to speak the Authorization API, and the PDP behind it becomes replaceable. In terms of the number of integrations, it is an attempt to reduce N×M to N+M.

This is not the first attempt to standardise authorisation: in the 2000s there was XACML¹, an OASIS standard. XACML comprehensively defined everything from the architecture to the policy language, but it is often said in retrospect that its complexity kept it from spreading. My understanding is that AuthZEN standardising only the communication, without stepping into the policy language, is a design decision informed by that history. Incidentally, the PDP and PEP distinction is also inherited from the architecture of that era.

What is in the specification

Authorization API 1.0 is a plain design of JSON over HTTPS, and a decision request is expressed with the following four elements.

subject: who (the principal of the access, such as a user or a workload)
action: what they are trying to do
resource: what the target is
context: environmental information used for the decision, such as time (optional)

For example, a decision request sent to POST /access/v1/evaluation looks like this.

{
  "subject": { "type": "user", "id": "alice@example.com" },
  "action": { "name": "can_read" },
  "resource": { "type": "document", "id": "123" }
}

The core of the response is a single boolean; additional information such as the reason for the decision is returned in an optional context field.

{ "decision": true }

There are five endpoints.

Access Evaluation: ask for a single decision
Access Evaluations: ask for multiple decisions batched into a single call
Subject Search / Resource Search / Action Search: ask not for a yes/no but for the list of subjects, resources, or actions that are allowed

The Search endpoints seem to be intended for screens like “show only the resources the user can access” in a list. With yes/no decisions alone you would have to query every item each time you render a list, so I found it practical that this is included in the specification from the start.

Comparison with OIDC

AuthZEN is sometimes introduced as “OIDC for authorisation”. Before looking into it this description didn’t click for me, but it fell into place once I lined up what each of them standardised.

What OIDC (OpenID Connect) standardised is authentication, that is, the part that confirms “who is here right now”. Because it was standardised, any application (RP) can be combined with any identity provider (OP), and delegating login to an IdP instead of building it yourself became the norm. AuthZEN is trying to make the same thing happen for authorisation, that is, “may this principal perform this operation?”.

	OIDC	AuthZEN (Authorization API)
Question answered	Who is here right now?	May this principal perform this operation?
What is standardised	Authentication flows, ID tokens	The decision request and response API
What it connects	App (RP) and identity provider (OP)	App (PEP) and authorisation engine (PDP)
When decisions happen	Mainly at login	Per request

In other words, the two are complementary rather than competing: OIDC establishes the “who”, which is placed in the subject, and AuthZEN is asked “may they?”. Both are OpenID Foundation specifications, so it looks like authentication and authorisation will be standardised side by side.

The word “authorisation” also made me think of OAuth 2.0, but their roles do not seem to overlap. What OAuth 2.0 scopes express is the coarse-grained question of “how much authority is delegated to this client”, while fine-grained per-request decisions such as “may this user approve this voucher?” remain inside the application. What AuthZEN handles is this remaining part.

Current status

Authorization API 1.0 was approved as a Final Specification by a vote of the OpenID Foundation membership in January 2026. That is a little over a year after it became an Implementer’s Draft in November 2024. A Final Specification is positioned as a stable version that will not be revised further, and the specification text is published on the OpenID Foundation’s site.

Another characteristic seems to be that interoperability testing was repeated in parallel with drafting, and the results of vendors connecting to each other are published on the AuthZEN Interop site. My impression is that products and services specialising in authorisation are leading the way in support; looking at more general-purpose stacks, Keycloak has started discussing support and OPA has an open issue requesting it, which is roughly the stage things appeared to be at.

Things have kept moving since the specification was finalised. In June 2026, two new working group drafts were published. One is a profile for situations where authorisation cannot be granted until approvals or additional checks are completed (the Access Request and Approval Profile), and the other is a profile for authorising MCP (Model Context Protocol) tool calls in the AuthZEN format. Both are aimed at authorisation for AI agents, and they seem to be at the stage of broadening the scope on top of the finalised 1.0. The question of what, and how much, to allow an agent to do was something I saw again and again at KubeCon + CloudNativeCon Japan 2026, so this area may end up being the entry point through which AuthZEN spreads.

What I want to try next

The specification itself is small, and standing up a single AuthZEN-capable PDP and calling the Authorization API looks like a reasonable entry point. I plan to verify things in roughly the following order and write them up as articles.

Stand up an AuthZEN-capable PDP and observe how the evaluation endpoint behaves
Use the Search endpoints to build a list of “only the things you can access”
Combine it with OIDC authentication and connect the authenticated principal to decision requests

References

eXtensible Access Control Markup Language. An OASIS standard that defined an authorisation architecture and policy language based on XML. The latest version, 3.0, was standardised in 2013. ↩