DEV Community: Luis Gustavo Lauermann Hartmann

Chapter 1 - The Problem: Authorization in Microservices Is Still Too Coupled

Luis Gustavo Lauermann Hartmann — Sat, 21 Feb 2026 15:48:19 +0000

Disclaimer

This article series is the result of a collaboration between @dominikpollok (co-student), @dboschert (Master’s student currently writing his thesis) and me.

The project was carried out under the supervision of the Cooperation and Management (C&M) research group at KIT. However, the perspectives and interpretations presented in this series reflect solely those of the involved students and do not necessarily represent the official views of C&M.

The related Master’s thesis will be referenced here once it has been completed.

All articles are written manually. An LLM is used exclusively for syntactic refinement and readability improvements.

The Security Trade-Off of Microservices

Among the many promised benefits of migrating from monolithic applications to microservices — scalability, independent deployability, and team autonomy — one challenge is often underestimated:

Securing many decoupled services is significantly harder than securing a single application.

Enterprise environments are already complex. Internal governance policies, client requirements, regulatory compliance, and security standards impose strict constraints on system design. When such constraints meet distributed architectures, complexity increases rapidly.

To cope with these demands, organizations frequently develop customized security solutions — including self-designed authorization protocols and, in some cases, even self-built authentication mechanisms.

Custom solutions may solve immediate problems, but they often slow down long-term change and innovation.

Authentication vs. Authorization — Still Confused in Practice

Two of the most fundamental concepts in IT security are authentication and authorization.

Authentication verifies a principal’s asserted identity or attributes.

Authorization determines whether an authenticated subject may perform a specific action on a resource under defined policies and contextual constraints.

These concepts are distinct — yet tightly coupled.

Authentication answers:

Who are you?

Authorization answers:

Given who you are, what are you allowed to do?

The coupling between authentication and authorization lies in trust.

Authorization decisions are made based on attributes — identity, roles, permissions, contextual properties. But those attributes must be trustworthy. Authentication provides that trust foundation.

If authorization were performed on unauthenticated or unverifiable claims, a subject could simply assert arbitrary roles or privileges. In such a system, policy evaluation would become meaningless, because the inputs to the decision process would not be reliable.

In other words:

Authentication establishes confidence in who (or what) is making the request.

Authorization evaluates what that authenticated principal may do.

Authorization without authentication reduces policy enforcement to accepting self-declared privileges.

Despite this conceptual clarity, many systems blur the boundaries in implementation.

The Common Anti-Pattern: Security Logic Inside Services

In practice, services often implement both authentication and authorization directly in application code. For example:

Verifying identity tokens in middleware or even inside MVC controllers
Performing hardcoded role checks inside business logic

Even when organizations rely on external IAM providers — which is generally advisable — services frequently:

Enforce authentication at the application layer
Depend on vendor-specific authorization protocols
Embed policy decisions directly into service logic

This creates tight coupling between business logic and security enforcement.

The Orchestration Problem

The deeper issue is not merely token validation or role checks.

It is the lack of a clear strategy for:

Orchestrating security across services
Distributing and enforcing business policies consistently
Managing identity propagation between services
Supporting region- or regulation-dependent policies

In microservice environments, different teams often develop services with different IAM expectations. The result is a heterogeneous security landscape where policies are interpreted and enforced differently across the system.

When company-wide governance policies enter the picture — for example, IT or security department mandates — complexity increases further. Services must not only enforce project-specific rules but also comply with overarching business policies.

“But Monoliths Have These Problems Too”

Yes — many of these issues also exist in monolithic architectures.

However, microservices amplify them.

Distributed systems introduce additional concerns:

Inter-service trust relationships
Identity propagation across boundaries
Policy evaluation consistency
Latency and availability of authorization decisions
Cross-region or multi-tenant policy variations

In a monolith, security flaws tend to be centralized.
In microservices, they become distributed and harder to reason about.

The Case Study

Considering the case study introduced in Chapter 0, we start with the following architecture:

The core components are:

InnoDocApp – the document portal used by external partners
InnoDocStore – the storage system containing internal documents
DB-Metadata – a metadata database storing document attributes relevant for access control

Ideally, document content and access-control metadata are stored separately. By isolating authorization-relevant attributes from the document storage itself, operational responsibilities remain cleanly divided: IT operations manage document storage, while InnoDocApp manages access-related metadata.

This separation, however, introduces new concerns — such as synchronization between documents and their metadata — which we will leave aside for now.

What Happens in this Architecture

In this initial model, when a request for a document arrives, InnoDocApp must:

Ensure the subject is authenticated
Determine whether the subject is authorized to access the document
- Compare subject attributes (roles, claims, etc.)
- Evaluate them against document attributes stored in DB-Metadata
Execute the corresponding database operations (download, read, etc.)

The critical issue:

Steps 1 and 2 are embedded directly into the application.

This tightly couples security logic with business logic — exactly the pattern we want to avoid.

Externalizing Authorization: The PXP Architecture

The OASIS work group introduced a standardized approach to externalize authorization decisions. Within the OASIS ecosystem — particularly in the context of XACML — this architectural pattern is known as the PXP architecture.

The PXP model separates authorization into clearly defined components:

1. Policy Enforcement Point (PEP)

An access request is received by the PEP.

The PEP:

Intercepts the request
Enforces the final decision
Does not make authorization decisions itself

Instead, it delegates the decision to the PDP.

2. Policy Decision Point (PDP)

The PDP evaluates whether a:

Subject
May perform an Action
On a Resource

It returns a decision such as Allow or Deny.

The PDP contains no business logic — only policy evaluation logic.

3. Policy Administration Point (PAP)

The PAP defines and manages the policies that govern access control.

It answers:

What are the rules?

4. Policy Information Point (PIP)

The PIP provides additional attributes required for decision-making:

Subject attributes (roles, department, clearance level)
Resource attributes (classification, ownership)
Contextual information (time, region, risk signals)

Without the PIP, the PDP would lack the data required to make informed decisions.

Why This Matters

The PXP architecture formalizes what we conceptually want:

Applications should not decide authorization.
Policies should not live in business code.
Decision logic should be centralized and replaceable.
Attribute retrieval should be separated from policy evaluation.

Instead of embedding authentication and authorization directly into InnoDocApp, we externalize policy evaluation and turn the application into a pure business component.

This architectural separation allows authorization to:

Scale independently
Be audited centrally
Be updated without redeploying services
Be standardized across teams

And this is exactly what our InnoDocApp scenario requires.

In the next chapter, we will apply the PXP model concretely to our case study and show how InnoDocApp can delegate authorization decisions entirely.

Chapter 0 - Decoupling Authorization from Microservice-Based Applications

Luis Gustavo Lauermann Hartmann — Sat, 21 Feb 2026 15:03:00 +0000

Disclaimer

This article series is the result of a collaboration between @dominikpollok (co-student), @dboschert (Master’s student currently writing his thesis) and me.

The project was carried out under the supervision of the Cooperation and Management (C&M) research group at KIT. However, the perspectives and interpretations presented in this series reflect solely those of the involved students and do not necessarily represent the official views of C&M.

The related Master’s thesis will be referenced here once it has been completed.

All articles are written manually. An LLM is used exclusively for syntactic refinement and readability improvements.

Preface

Most computer science students learn how to build applications.

Far fewer learn how to protect them properly — or how to design security mechanisms that scale across distributed systems.

This semester, I took a course on microservice system architecture. It combined theory with a practical project, and the practical part turned out to be the most impactful: I had the opportunity to assist a master’s thesis focused on externalized authorization using Decentralized Identities (DI).

Decentralized Identity is gaining significant traction in Europe, especially with initiatives such as EUDI. But beyond the identity landscape itself, what truly caught my attention was a more fundamental architectural question:

How do you design authorization for distributed systems in a clean, reusable, and maintainable way?

This series explores that question.

The focus is on architecture — design decisions, trade-offs, and structural patterns that make authorization scalable across distributed services.

Rather than discussing theory in isolation, the concepts presented here are backed by a working proof of concept. The implementation under development can be found in my GitHub repository:

👉 https://github.com/Luis-Guga/InnoDocAuthZEN

There is no “astronaut architecture” here — only practical experimentation and applied design.

The Scenario

Let’s imagine a company called InnoComp.

InnoComp manages multiple projects. Each project produces internal documentation stored in a centralized repository — we’ll call it InnoDocStore.

Alice is a project manager at InnoComp. Her team requires expertise in a domain outside their specialization, so she hires John, an external partner from another company.

John needs access to selected project documents — but certainly not all of them.

He is:

Not an internal employee
Not part of the company’s identity infrastructure
Not inherently trusted

To enable controlled access, InnoComp introduces InnoDocApp — an application that acts as a secure gateway for external collaborators. It allows partners like John to access specific internal documents under strict authorization constraints.

You can think of InnoDocApp as a controlled exposure layer over internal resources.

The architecture treats documents as valuable objects and aims to minimize their exposure to external employees by securing InnoDocApp. We assume that InnoDocStore is already secured.

The Policy Problem

Alice and InnoComp’s security manager define a formal access policy:

Who can access which documents, and under what conditions?

We’ll call this policy InnoDocAccessPolicy.

At this point, the real architectural challenge begins.

How do we enforce this policy in a way that is:

Structured
Maintainable
Reusable
Robust
Scalable across multiple applications

This is not just about securing a single application. It is about designing a system that can enforce consistent authorization logic across an ecosystem of services.

What We Don’t Want

There are several straightforward approaches:

Implement authentication directly inside InnoDocApp
Protect endpoints at the controller level (e.g., in an MVC architecture)
Embed an authorization service within the application itself

All of these approaches are technically viable.

And all of them introduce architectural coupling.

The problem emerges the moment a second application with similar Identity and Access Management (IAM) requirements is introduced.

Now we must replicate:

Authentication logic
Token validation
Policy enforcement
Authorization rules

Security logic begins to spread across services.

What started as a convenient implementation becomes distributed architectural debt.

This is precisely what we want to avoid.

What This Series Will Cover

In this series, I will walk through the architecture we developed — including the reasoning behind it, the trade-offs we encountered, and the mistakes we made along the way.

The goal is to show how authorization can be decoupled from application logic and treated as first-class architectural concern.

If you are building distributed systems and want them to scale securely beyond a single service, this exploration may offer a useful perspective — and perhaps help you avoid embedding security logic in places you’ll later regret.