AuthZEN.guide

OpenID AuthZEN: the standard Authorization API, explained

By David Brossard, Co-chair of the OpenID AuthZEN WG and editor of the Authorization API 1.0 · Built by Axiomatics · Last updated

OpenID AuthZEN is the OpenID Foundation standard for externalized, fine-grained authorization. Its Authorization API 1.0 defines a simple JSON-over-HTTPS contract that any application, API gateway or identity provider (the Policy Enforcement Point, PEP) can use to ask any authorization engine (the Policy Decision Point, PDP): can this subject perform this action on this resource, in this context? The PDP answers with a decision. Policy language, engine and vendor become swappable.

Status: Authorization API 1.0 is a Final Specification

How AuthZEN works

The PEP sends an HTTPS POST to the PDP's evaluation endpoint. The default path is /access/v1/evaluation:

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json

{
  "subject":  { "type": "user", "id": "[email protected]" },
  "resource": { "type": "account", "id": "123" },
  "action":   { "name": "can_read", "properties": { "method": "GET" } },
  "context":  { "time": "1985-10-26T01:22-07:00" }
}

The PDP responds:

{ "decision": true }

The API covers five operations, plus a discovery document:

APIDefault pathUse it to…
Access Evaluation/access/v1/evaluationCheck one subject/action/resource
Access Evaluations/access/v1/evaluationsBatch many checks in one call (e.g. render a UI)
Subject Search/access/v1/search/subjectWho can do X on Y?
Resource Search/access/v1/search/resourceWhich resources can Alice read? (list filtering)
Action Search/access/v1/search/actionWhat can Alice do on Y?
PDP metadata/.well-known/authzen-configurationDiscover endpoints and capabilities

Full API reference with JSON examples →

Why AuthZEN?

Authentication was standardized long ago with SAML and OpenID Connect. Authorization was not: every application hard-codes its own checks, and every externalized authorization product exposes its own proprietary API. That leaves gaps in access control and locks organizations into a single vendor.

Talks, webinars and interops

AuthZEN: the "OpenID Connect" of authorization (Gartner IAM 2025)

A year after AuthZEN was first introduced to Gartner attendees, this session reviewed progress after two rounds of interops, then three new interops covering API gateways, the AuthZEN Search API and identity provider integrations. The point: IAM teams can externalize and standardize authorization across their application estate without being locked in to a proprietary API, a key step towards the Zero Trust enterprise.

OpenID AuthZEN overview, Gartner IAM 2025 by David Brossard

OpenID AuthZEN webinar (December 2025)

A walkthrough of the Authorization API ahead of its approval as a final specification: the subject/action/resource/context model, the evaluation, batch and search endpoints, and how PEPs and PDPs interoperate.

Identiverse 2024 interop

The first public AuthZEN interop. Multiple vendors' PDPs answered the same Access Evaluation requests from a shared sample application, showing that one PEP can work against many authorization engines. Read the OpenID Foundation interop results.

AuthZEN FAQ

What is OpenID AuthZEN?

OpenID AuthZEN is an OpenID Foundation working group that standardizes how applications ask for authorization decisions. Its first specification, the Authorization API 1.0, defines a JSON-over-HTTPS API that a Policy Enforcement Point (PEP) uses to ask a Policy Decision Point (PDP) whether a subject can perform an action on a resource in a given context.

Is the AuthZEN Authorization API final?

Yes. The OpenID Foundation membership approved Authorization API 1.0 as a Final Specification on 12 January 2026.

How does AuthZEN relate to OAuth 2.0 and OpenID Connect?

They are complementary. OpenID Connect authenticates the user and OAuth 2.0 delegates and scopes access through tokens. AuthZEN answers the fine-grained, runtime question of whether this subject may perform this action on this resource right now. Token claims typically become subject.properties in an AuthZEN request.

Does AuthZEN replace XACML, OPA/Rego, Cedar or OpenFGA?

No. AuthZEN standardizes the API between the application and the decision engine, not the policy language. A PDP can evaluate ALFA/XACML, Rego, Cedar, relationship tuples or anything else behind an AuthZEN endpoint. See AuthZEN vs XACML, OPA, Cedar and OpenFGA.

What does an AuthZEN request contain?

A subject (type and id), an action (name), a resource (type and id), each with optional properties, plus an optional context. The PDP returns a JSON object with a boolean decision and an optional context, for example reasons or obligations.

How does a PEP discover an AuthZEN PDP?

A PDP publishes metadata at /.well-known/authzen-configuration listing its policy_decision_point identifier and endpoints such as access_evaluation_endpoint, access_evaluations_endpoint and the search endpoints.

Can AuthZEN be used to authorize MCP servers and AI agents?

Yes. The working group is drafting COAZ, a framework for mapping other protocols into the subject-action-resource-context model, and a COAZ-MCP binding that maps Model Context Protocol JSON-RPC messages to Authorization API requests. Both are working group drafts, not yet final.

About and contact

AuthZEN.guide is maintained by David Brossard, CTO of Axiomatics, co-chair of the OpenID AuthZEN Working Group and an editor of the Authorization API 1.0. It is an independent explainer. The normative text is the OpenID specification.