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.
Top comments (0)