OpenID AuthZEN

OpenID AuthZEN is a Working Group under the OpenID Foundation dedicated to developing standards and promoting interoperability in the realm of authorization. Its aim is to create a standardized framework for applications to communicate with policy-based authorization systems by defining common protocols and formats for fine-grained authorization decisions — essentially serving as the “OpenID Connect” for authorization processes. Acting as a bridge between policy decision points (PDPs), identity providers, and API gateways, OpenID AuthZEN ensures seamless, standardized authorization across enterprise IT environments.

Key features

At its core, AuthZEN provides a standardized authorization request/response API applications can use to delegate authorization decisions to a third-party authorization service such as policy-based authorization including Axiomatics’ Orchestrated Authorization. This enables consistent fine-grained access, dynamic separation of duty, and many more access control use cases across a range of applications.

More importantly, OpenID AuthZEN enforces the principle of least privilege, along with continuous authorization enforcement. As a consequence of its architecture, iIt allows for comprehensive auditability and compliance while maintaining consistency across applications and services. By prioritizing interoperability, security architects and product owners can achieve greater transparency, security, and seamless implementation.

Additional key features include:

Standardized Evaluation API

AuthZEN provides a standard information model representing an authorization request and response. It is JSON-based and is structured based on the grammatical function of a sentence:

Can Alice view record #123 at 1:22 am?

• Alice is an attribute of the subject category
• Record and #123 are attributes of the resource
• View is an attribute of the action, and
• 3:04pm is an attribute of the context

The model includes the following entities:

• Subject,
• Action,
• Resource,
• Context, and
• Decision.

The example aforementioned maps out as follows:

Open to all authorization models

The goal of OpenID AuthZEN is to provide a standard interface on top of any type of authorization implementation, including:

• Policy-based policy decision points (PDP), such as
  • An eXtensible Access Control Markup Language (XACML) engine
  • An Abbreviated Language for Authorization (ALFA) engine
  • Open Policy Agent (Rego)
  • Proprietary languages
• Graph-based models
• Access control lists (ACLs)

This allows practitioners to seamlessly switch between different authorization implementations without jeopardizing existing integrations.

Formalizes common authorization design patterns

In addition to defining a standard request/response for the PEP-PDP pattern, OpenID AuthZEN also defines three key patterns:

• The PEP-PDP design pattern as formalized by NIST ABAC 800-162 — this is the optimal approach for runtime & continuous authorization.
• Dynamic claims generation: Also known as token-based authorization, this pattern allows dynamic claims to be injected inside of an access token that is then sent to the target application (the relying party). Authorization checks are performed by the app inside the app.
• Entitlements provisioning: This approach works for those apps that cannot be protected by a PEP and have a rich authorization model built into the application logic. Assuming the application exposes a means to provision authorization configuration, then the centrally maintained policies can be converted into the application’s specific format and provisioned.

Discovery Endpoint

OpenID AuthZEN will include a discovery endpoint that describes which services and features the AuthZEN PDP supports. The discovery endpoint is on the roadmap for the first half of 2025.

Partial Evaluation API

The first AuthZEN API focuses on “binary” authorization requests and responses. For example:

• Can Alice view record #123?
• Yes, Alice can view record #123.

But sometimes, authorization isn’t a yes/no question. Sometimes, we need to ask broader questions, such as what actions a user can do or who can access a document. To address these open-ended questions, AuthZEN provides the Partial Evaluation API. With partial evaluation, we can ask:

• What can a given user do?
• Who can access a given resource?
• What action is possible?

The response will return in the form of predicates, which can then be translated into platform-specific filters, such as SQL or GraphQL queries. For example:

• Question: What can Alice view?
• Response:
  • Alice can view records in sales, or
  • Alice can view records she owns, or
  • Alice can view published records that are marked as public.

Search API

ALFA allows the specification of obligations (mandatory actions to be performed by the policy enforcement point) and advice (optional actions) alongside access control decisions.

Integration with XACML

The AuthZEN API specification maps directly to the AuthZEN XACML/JSON REST API. For an example of the translation, check out authzen-xacml-interop.

Interoperability with other standards

OpenID AuthZEN aims to interact with corollary standards such as OpenID Shared Signals and IETF’s OAuth 2.0 framework. A proposal has been made to extend OAuth Rich Authorization Requests (RAR) to support AuthZEN.

AuthZEN Evaluation API Structure

The following section describes the request/response protocol as defined in the latest implementer’s draft.

Request

The Access Evaluation request is a 4-tuple constructed of the four previously defined entities:

• Subject: REQUIRED. The subject (or principal) of type Subject.
• Action: REQUIRED. The action (or verb) of type Action.
• Resource: REQUIRED. The resource of type Resource.
• Context: OPTIONAL. The context (or environment) of type Context.

Response

The simplest form of a response is simply a boolean representing a Decision, indicated by a “decision” field.

• decision:
  REQUIRED. A boolean value that specifies whether the Decision is to allow or deny the operation.

In this specification, assuming the evaluation was successful, there are only 2 possible responses:

• true: The access request is permitted to go forward.
• false: The access request is denied and MUST NOT be permitted to go forward.

The response object MUST contain this boolean-valued Decision key.

Example Payloads

Axiomatics and OpenID AuthZEN

Axiomatics is a proud founding member of the OpenID AuthZEN Working Group and our CTO is one of the co-chairs of the group. Axiomatics regularly represents AuthZEN at conferences such as Gartner IAM, the European Identity Conference, and Identiverse.

Listen to our podcast episode All things ALFA: Talking Authz Policy and AuthZEN to learn more about the history of AuthZEN, and how enterprises can adopt it and contribute to the standard.