Authorization Exchange, or AuthZEN for short, is a new specification from the OpenID Foundation that aims to bring clarity and standardization to authorization. If OAuth 2.0 and OpenID Connect brought us standardized protocols for authentication and identity, AuthZEN aims to do something similar for fine-grained authorization. It defines a shared, interoperable way for applications to request and receive authorization decisions. The AuthZEN working group has even compared it to becoming “the OpenID Connect of Authorization.”

Organizations have long struggled with many different approaches to authorization. Modern systems increasingly require fine-grained, contextual authorization, with permissions that adapt to time, environment, data classification, business logic, and real-time risk signals. However, most companies still rely on access control lists (ACLs), roles, and static integration code. AuthZEN proposes a unified approach that simplifies the way applications and services communicate with authorization systems.

The Problem AuthZEN Solves

The authorization ecosystem has attempted standardization in the past. One example is eXtensible Access Control Markup Language (XACML), an XML-based language for defining attribute-based access control (ABAC) policies. However, XACML adoption has been relatively low, and the number of different solutions available in the market over the last decade has been growing.

Many enterprises deploy a mixture of authorization models for historical reasons, and each comes with its own enforcement approaches, data formats, and integrations. A policy enforcement point (PEP) written to speak to one engine, such as XACML or Open Policy Agent (OPA), the cloud-native policy engine, cannot talk to another without substantial rewriting. As a result, switching to a new authorization system often means a rewrite of some part of every application that depends on it.

This situation leads to significant lock-in and operational complexity. Over time, enterprise environments become a mix of incompatible approaches. Microservices apply one style of policy logic, API gateways another, and SaaS systems yet another. Security teams face challenges trying to ensure consistent enforcement and to respond quickly to new regulatory requirements. Auditing who had access to what and why across such a landscape becomes cumbersome and prone to error.

Equally problematic is that many organizations continue to handle authorization at login time, embedding roles or attributes in tokens and allowing them to live long beyond the context in which they were issued. Today’s applications require decisions that change dynamically. For instance, a banking application might need to know whether a teller can approve a financial transaction in their own branch after 6 PM, or if a service identity can access a dataset when specific environmental conditions are met. Traditional role-based access control (RBAC) or ACL systems cannot express these relational or contextual nuances in a scalable way.

Simply put, the root issue is that while we have standards for authentication and identity, we lack a standard protocol for exchanging authorization decisions. AuthZEN aims to solve this.

How AuthZEN Works

AuthZEN introduces a JSON-based decision API that formalizes how a PEP, whether an application, API gateway, microservice, or backend system, asks a policy engine (PDP) for a decision. The request can describe the subject making the request, the resource being accessed, the action that is intended, and any relevant contextual information. The PDP responds with a clear allow or deny decision, and may add additional metadata to the response to indicate things such as if step-up authentication is required, masking particular fields, or metadata for audit or logging purposes.

One of AuthZEN’s key design choices is remaining agnostic about policy models. The specification does not attempt to enforce what authorization should look like internally. Instead, it focuses on the interface between enforcement and decision-making. Behind an AuthZEN interface, organizations can continue using RBAC, ABAC, ReBAC, XACML, graph-based approaches, Rego, Cedar, or even fully proprietary engines. What matters is that the request and response format remains consistent and interoperable.

Having an abstraction layer for policy languages is key: once applications speak AuthZEN, they no longer need to be tightly coupled to any particular PDP. A PEP built today can interact with tomorrow’s policy engine without code changes.

Where AuthZEN Fits in Modern Architectures

The value of AuthZEN becomes especially clear when examining how it may be used across different parts of an enterprise.

API Gateways

One compelling area is API gateways, which commonly serve as central enforcement points. Gateways often struggle to apply fine-grained authorization consistently, falling back on coarse-grained rules that often allow broad access. With AuthZEN, a gateway can evaluate resource-specific policies in real time, receive masking or redaction instructions, and enforce decisions based on sensitive attributes or regional requirements, all without embedding this logic internally or relying on proprietary extensions.

Zero-Trust Architectures

A second domain is microservices operating within zero-trust architectures. Zero trust principles need continuous evaluation rather than one-time authorization at login. Services need a way to ask for decisions on each request or at critical points in a workflow. AuthZEN provides the contract through which those decisions can be outsourced cleanly to a PDP, giving organizations the ability to enforce least-privilege access dynamically across service-to-service communication.

Governance For Data Access

The model extends well to data access scenarios, too. Analytics systems, data lakes, and search platforms frequently require decisions about what data can be exposed, under what conditions, and if parts of the data should be redacted. AuthZEN can add metadata in authorization responses, enabling data governance and compliance.

How AuthZEN Could Change Enterprise Authorization

If AuthZEN achieves broad adoption, its impact on enterprise security architecture could be significant. It would reduce the problem of vendor lock-in, which has long been a problem and a risk for organizations. Applications would no longer need specific integrations for each policy engine. Organizations could shift to new systems gradually, use multiple PDPs for different use cases, or run hybrid approaches, all without modifying enforcement logic across multiple applications.

A unified decision API would also bring long-needed consistency to authorization itself. Instead of each service interpreting policies differently or implementing its own subset of business rules, enterprises could centralize decisions in policy engines with well-defined domain-specific policies. This enables uniform and centralized auditing and governance. When policy logic moves out of application code and into a centralized policy layer, it becomes easier to version, review, and test.

For developers, AuthZEN offers a more predictable and standardized approach. Rather than learning the ins and outs of potentially multiple vendors or systems, they interact with a single API and spend less time writing code or reimplementing authorization logic. This frees engineering teams to focus on product features instead of implementing security capabilities.

AuthZEN Improves Enterprise Authorization

Enterprises today face a deeply fragmented authorization landscape, where applications, services, data systems, and SaaS platforms often operate with incompatible policy models and inconsistent enforcement strategies. AuthZEN seeks to address this by defining a standard JSON-based API through which policy enforcement points request authorization decisions from policy decision points.

By remaining policy-agnostic and focusing on the interface rather than the internal mechanics of authorization, AuthZEN aims to decouple applications from specific policy engines and reduce both vendor lock-in and integration complexity. Its design supports dynamic, context-aware decisions that better reflect the needs of cloud-native, distributed, and zero-trust architectures.

If adopted widely, AuthZEN could bring consistency to enterprise authorization, improve governance and auditability, enhance developer experience, and bring more secure and adaptable systems. In many ways, it aims to do for authorization what OAuth and OpenID Connect did for authentication.