AuthZEN: Standards-based authorization for enterprises

Published by Alex Olivier on October 02, 2025
AuthZEN: Standards-based authorization for enterprises

Authentication has benefited from strong standards over the years. SAML, OAuth 2.0, and OpenID Connect gave us a stable foundation for authentication and allowed vendors like Auth0 and Okta to offer ready-made solutions. Both became widely adopted.

Authorization has not reached that singularity yet. Without standards, every app bakes authorization logic differently, producing overprovisioned roles, spaghetti code, and inconsistent checks across services. This fragmentation mirrors the pre-standard authentication world.

This was one of the core topics we co-presented at the European Identity Conference 2025, and the slide below illustrates the contrast: authentication is largely “solved” through standards, while authorization is still broken and inconsistent.

State of IAM.png

 

Modern authorization approach

Here is the model we believe represents the future of enterprise authorization. It is a shift away from authorization logic hardcoded inside applications and static RBAC models toward centralized, policy-driven authorization. Modern authorization is defined by four key principles:

  • Externalized.
    Authorization logic is moved out of application code and into a dedicated service that evaluates requests against centrally managed policies. This separation avoids duplicated checks, enables policy changes without redeploying applications, and provides a single control plane for enforcement across applications, services, and APIs. Learn more about externalized authorization here.

  • Fine-grained and contextual.
    Instead of relying only on roles, decisions consider multiple attributes about both users and resources. Access can depend on factors such as department, ownership, sensitivity, device, or time of day, allowing precise and auditable control.

  • Runtime.
    Policies are evaluated in real time when access is requested, ensuring decisions reflect the most current context.

  • Relationship-aware.
    Access rules account for the relationships between users, services, and resources, not just static roles.

modern authorization approach.png

This approach is flexible, future-proof, and adaptable, avoiding authorization silos. But how that externalized interface works is the core of what AuthZEN is all about.

 

A standard for authorization

The absence of a common approach has left enterprises and vendors with fragmented ways of performing authorization and access control checks. After speaking with hundreds of IAM leaders and engaging with the community at conferences, we hear similar concerns being escalated across the software development industry:

  • Many applications use different authorization models. This adds architectural complexity and forces teams to keep reinventing the wheel every time they build something new
  • Proprietary APIs create lock-in and make it costly to change tools when requirements shift.
  • When authorization is often implemented differently across different services, it leaves organizations without a clear or auditable view of access.

Legacy Authorization Models.png

AuthZEN is designed to solve these gaps. It gives systems a common interface supporting interoperability and reducing vendor lock-in risk. This is the authorization’s OAuth moment.

Note on how AuthZEN compares to OAuth or OpenID Connect:
OAuth and OpenID Connect solved the problem of authentication, identity federation, and single sign-on. They define when users log in and how identity information is exchanged between systems. AuthZEN addresses the next step, which is authorization. If OAuth is about proving who you are, AuthZEN is about proving what you are allowed to do.

 

What is AuthZEN?

AuthZEN is an emerging standard from an OpenID Foundation working group that aims to make authorization interoperable across apps, APIs, and services. It sets out how a policy enforcement point (PEP), such as an application, API gateway, or IdP, communicates with a policy decision point (PDP), the external engine responsible for authorization decisions.

AuthZen model.png

This common request and response model gives companies a way to externalize authorization decisions and enforce policies consistently across multiple systems. AuthZEN does not replace existing policy engines. It standardizes the interface between the enforcement point and the decision point.

AuthZEN was chartered by the OpenID Foundation in 2023. Its purpose is to bring the same level of consistency for AuthZ that OpenID Connect delivered for AuthN.

Cerbos and AuthZen.png

The Cerbos team is part of this working group alongside other vendors and security leaders. We contributed to the first round of interoperability testing and achieved conformance with the AuthZEN request and response protocol. We also participated in live demos at Identiverse and the Gartner IAM Summit, demonstrating multiple engines exchanging authorization decisions through a single API.

NOTE

It’s important to understand that AuthZEN does not define what the policy engine does; it defines the standard interface between enforcement points and decision points. Cerbos is an enterprise-grade authorization solution that adopts this model for communication between components. Enterprises can adopt Cerbos for fine-grained, contextual, and continuous authorization, with the confidence that it already aligns with AuthZEN and will integrate seamlessly with any compliant ecosystem as the standard matures.

This collaboration is what moves AuthZEN from a draft into a practical standard that enterprises can trust. AuthZEN specification is scheduled to hit v1.0 in Q4 2025.

 

The scope of the AuthZEN specification in 2025 and how it works

The specification itself focuses on the boundary between the policy enforcement point, which is the application or API gateway, and the policy decision point, which is the external authorization engine. Applications built against the AuthZEN API can call any compliant engine without code changes.

The AuthZEN request model is intentionally simple. A request is expressed in JSON with four elements (these are the main entities in an AuthZEN request):

  • Subject is the entity making the request, such as a user or service
  • Action is the operation being requested
  • Resource is the object being accessed
  • Context is optional metadata, such as time, IP, or request environment

The AuthZEN request model.png

Example AuthZEN request

Here's how a basic AuthZEN authorization request looks. This shows how a client application (the PEP) asks the authorization engine (the PDP) whether a user can perform an action on a specific resource:

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

Here is how the PDP's response to a decision will look:

{
  "decision": true
}

The response is a simple yes or no that the application enforces. This consistency is what enables interoperability across vendors.

AuthZEN also supports richer requests and responses. For example, a request can include attributes like department, IP address, or device ID. Responses can include structured reasons for denial, in multiple languages, or metadata that triggers step-up authentication or redacts fields.

The specification also supports batching of these requests, a set of Search APIs, a Discovery endpoint, and initial groundwork for supporting partial evaluations in future versions.

 

Why AuthZEN matters for enterprises

The benefit of AuthZEN is interoperability. A PEP implemented once can talk to any compliant PDP, no matter what policy language or engine sits behind it. That gives enterprises real choice in their authorization stack.

Implementing a single authorization engine across your multiple services also addresses some of the compliance requirements by providing a consistent audit log of actions taken by users and systems. Regulations such as GDPR, HIPAA, PCI DSS, and DORA demand precise, auditable authorization controls.

Having an authorization check behind every service also simplifies the implementation of a Zero Trust approach, where no user or service is trusted by default and every access request must be verified. AuthZEN provides a consistent way to perform those verification checks across heterogeneous systems.

We, as a company, truly believe that AuthZEN is the future of authorization and are proud to support it with Cerbos.

Learn more:

 

Key takeaways

  • Authentication is already standardized through SAML, OAuth 2.0, and OpenID Connect, but authorization has lacked a unifying approach. AuthZEN, an OpenID Foundation standard, is filling that gap by defining how applications communicate with policy engines through a common request model of subject, action, resource, and context.

  • Modern authorization is shifting away from hardcoded logic and static roles toward four principles: externalized, fine-grained and contextual, runtime, and relationship-aware. This approach enables consistent, adaptable, and auditable access control across systems.

  • AuthZEN addresses fragmentation and vendor lock-in by creating a common interface that allows enterprises to swap or combine engines without rewriting applications. Cerbos is part of the working group driving this standard, having demonstrated interoperability at Identiverse and the Gartner IAM Summit.

  • As an enterprise-grade authorization solution, Cerbos already aligns with AuthZEN, delivering fine-grained, contextual, and continuous authorization across applications, APIs, workloads, and AI agents. With AuthZEN v1.0 expected in Q4 2025 and a roadmap including partial evaluation, discovery APIs, and ecosystem integrations, enterprises now have a clear path to standardized, future-proof authorization

FAQ

How does AuthZEN support zero trust?

What is externalized authorization management?

How does AuthZEN reduce vendor lock-in?

Book a free Policy Workshop to discuss your requirements and get your first policy written by the Cerbos team