The Policy Decision Point in practice: integration patterns for AuthZEN in existing IAM landscapes

June 2026

Author: Sadrick Widmann

Part 2 of our blog series with our partner Consulteer InCyber. In Part 1 we showed, why traditional IAM architectures have a fundamental authorization problem a and why AuthZEN is the necessary standard for a true Zero Trust architecture.

This part is about practice: where the Policy Decision Point sits, how the Policy Enforcement Points get into your applications, and how to succeed with the rollout without rebuilding your existing landscape.

From the why to the how

The diagnosis from Part 1 is clear: as long as authorization logic is buried in application code, it stays opaque, hard to audit, and slow to change. Every rule change means a deployment, every new application reinvents its own permission logic – and Zero Trust remains an architecture diagram rather than a lived reality.

The solution is externalizing authorization: applications send standardized requests, a central instance decides. AuthZEN, the standard from the OpenID Foundation, defines the interface for this.

But between understanding the standard and a production integration lie very concrete architectural questions. Those are exactly what we answer here – with the integration patterns that have proven themselves in practice.

The Policy Decision Point: the brain of access control

As a reminder, the three roles from the NIST reference model: the Policy Decision Point (PDP) evaluates policies and makes the decision. The Policy Enforcement Point (PEP) sits wherever access actually happens – at the API gateway, in the service, or in the application – queries the PDP, and enforces its decision. The Policy Information Point (PIP) supplies the attributes and context data that make a decision intelligent.

In practice, where you place the PDP determines success or frustration:

Central PDP: one instance, all policies in one place. Maximum consistency and auditability – the right choice for most landscapes and the natural starting point.
Distributed PDP instances: in latency-critical scenarios (e.g. high-frequency APIs), PDP instances can run close to the services. The policies remain centrally managed and are distributed to the instances as Policy-as-Code – consistency without a latency trade-off.
Decision caching: recurring, identical requests can be cached for short time windows. Important: context-dependent decisions (risk score, location) may only be cached very briefly, if at all – otherwise the cache undermines the very dynamism you introduced AuthZEN for.

In cidaas, the PDP runs either centrally or distributed – both operating models are supported out of the box, so you can choose (or combine) the model that fits your latency and consistency requirements.

policy decision point

Behind the AuthZEN interface, cidaas provides a complete authorization framework:

Policy-as-Code using the Rego policy language on top of the Open Policy Agent (OPA), as well as Relationship-Based Access Control (ReBAC) for relationship-based permissions – with no lock-in to proprietary solutions.

Four integration patterns that have proven themselves

The good news first: AuthZEN does not require a rebuild of your landscape. The standard complements your identity infrastructure – IAM, CIAM, and identity provider stay as they are. The only question is where the PEPs sit. Four patterns cover practically every scenario.

Pattern 1: PEP at the API Gateway

The pattern: the API gateway intercepts every request, builds the AuthZEN request (subject, action, resource, context), and queries the PDP before the request reaches the backend service.

When it fits: the fastest entry point of all. Ideal for API authorization toward partners, integrations, and external apps – without a single change to the backend applications.

Pitfall: the gateway only sees what is in the request. For decisions at the level of individual records (e.g. may this user delete this document?), the gateway layer is often not enough – in that case you combine Pattern 1 with Pattern 3.

Pattern 2: Sidecar in the Service Mesh

The pattern: in microservices architectures, the PEP runs as a sidecar next to each service. Every service-to-service call is authorized consistently – a key building block for Zero Trust in east-west traffic as well.

When it fits: Kubernetes-based landscapes with many services and multiple teams. Authorization becomes an infrastructure property: no team can forget it or implement it differently.

Pitfall: watch the latency budget per hop. This is where distributed PDP instances and decision caching play to their strengths.

Pattern 3: Middleware or SDK in the application

The pattern: the application itself issues AuthZEN requests at the relevant points – via middleware in the request path or targeted SDK calls in the business logic.

When it fits: wherever fine-grained decisions at the resource level are needed: admin backends, back-office portals, employee portals with approval and release workflows, multi-tenant SaaS with tenant-specific policies.

Pitfall: the temptation to hard-code “just this one exception” after all. The discipline is: the application asks, the PDP decides – always.

Pattern 4: Legacy integration via upstream enforcement

The pattern: legacy applications whose code cannot or should not be touched are placed behind a reverse proxy or gateway acting as the PEP. The application itself stays unchanged; coarse-grained decisions (who may reach which module, path, or function?) are enforced upstream.

When it fits: grown landscapes with applications for which refactoring would be uneconomical. The pattern brings even legacy systems under central, auditable policies – and creates the basis to migrate them to Pattern 3 step by step later.

Pitfall: expectation management. You won’t achieve field-level permissions inside the legacy application this way – but you will get consistent, traceable access decisions at the entrance, and that is often the biggest security gain.

The rollout: pilot instead of big bang

In practice, externalized-authorization projects rarely fail on the technology – they fail on too large a first step. The proven approach:

Choose a pilot use case. An API service with clearly defined permission requirements is the ideal candidate. Small enough for quick results, representative enough to derive patterns for scaling.
Define the request schema. How are subject, action, resource, and context modeled in your organization? Once these conventions are cleanly defined, they become the reusable vocabulary for every application that follows.
Build policies as Policy-as-Code. With Rego, policies are defined declaratively, versioned, and rolled out in controlled steps – including a review and test process like the one you know from code. Changes to business rules no longer require an application deployment.
Scale horizontally. With the pilot as a blueprint, further applications are connected, each according to the pattern that fits it. The policy patterns and the request schema are already in place.

How AuthZEN in cidaas supports this path – from the central decision layer through Rego-based policy management to the standardized interface – is described in detail on our feature page.

Context makes decisions intelligent: the PIP connection

The real added value over static roles comes from context. The Policy Information Point supplies the PDP in real time with the attributes that turn a role check into a risk-based decision: department and cost center from the identity provider, location and access time from the request, risk scores from security telemetry, sensitivity levels from the resource metadata.

A typical AuthZEN request from an employee portal then looks like this:

“`json
{
“subject”: {
“id”: “user-2481”,
“attributes”: { “department”: “finance”, “risk_score”: “low” }
},
“action”: { “name”: “approve_order” },
“resource”: {
“type”: “purchase_order”,
“id”: “po-2026-0815”,
“attributes”: { “amount”: 24000, “cost_center”: “cc-110” }
},
“context”: { “mfa_age”: 240, “location”: “DE”, “business_hours”: true }
}
“`

The policy in the PDP can now express what was previously handled through role explosion: order approvals above 20,000€ only for the finance department, only with current MFA, only during business hours – and not at all when the risk score is elevated.

One rule, defined centrally, enforced everywhere.

Governance and sovereignty as a side effect

Externalizing authorization gains you more than architectural elegance. Central policies mean auditors can see at the push of a button which rules apply and why access was granted – a significant advantage in regulated environments, for example under NIS2 or DORA. Decisions are reproducible instead of hidden in code logic.

And because cidaas relies on open standards – AuthZEN, OAuth 2.0, OpenID Connect, Rego/OPA – and is hosted in Germany and the EU, policies, decision logic, and identity data are subject to European jurisdiction at all times. The decision layer thus becomes not only central and auditable, but sovereign.

Conclusion: the path is shorter than it looks

AuthZEN integration is not a platform rebuild but an incremental path: one pilot, one suitable integration pattern, a growing body of Policy-as-Code. The API gateway pattern often delivers first results in weeks, not months – and every additional application benefits from the schema already established.

Authorization must not become the bottleneck of your platform architecture. With a standardized Policy Decision Point it becomes, instead, the infrastructure layer that scales with your business.