From monolith to microservices: When and how to externalize identity and authentication

Why (and how) I externalized identity and authentication

This experience report complements my identity OIDC and microservices support for teams that need to evolve an existing system without breaking production.

When "it works" is no longer enough

At first, everything is simple: a single application, a monolithic backend, and a central database.

Authentication naturally lives inside the application core: a users table, a few roles, a homegrown session system. Nothing extraordinary, and nothing that causes problems.

But this balance never lasts very long. As the product grows, it starts to exist through several applications: a new web interface, a mobile app, internal tools (back office, support, administration), and progressively independent business services.

The monolith, once the only captain on board, must now become a service provider. Authentication, once a simple internal detail, suddenly becomes a cross-cutting concern.

Where do we log in? Who manages permissions? Should each application maintain its own identities and sessions?

If the answer to that last question is no, a structuring question appears:

Should the monolith become the central point of identity?

Very quickly, the stakes become clear:

allow all applications to share the same identity system
avoid re-implementing security for every new service
evolve the existing system without rewriting everything

What "moving to microservices" really means

The false debate: "microservices or not"

At this stage, the temptation is strong to answer: microservices. But the real goal is not "microservices everywhere". The real goal is:

create clear boundaries
stabilize interfaces
avoid breaking production
keep shipping product

The split is not an end in itself, it is a way to regain control.

A realistic trajectory

In most organizations, the trajectory looks like this:

Short term: the monolith becomes an API provider (system of record)
Mid term: some business capabilities are extracted into dedicated services
Long term: the monolith shrinks... or gradually disappears

In other words: you do not destroy the monolith, you open it up.

The real risk when you open the monolith

As soon as the monolith is consumed by something other than itself, the number one risk is no longer performance, it is security and governance. Very quickly, you must handle:

tokens via OAuth2 and OpenID Connect
multiple client types (web, mobile, internal tools)
consistent roles and permissions
audit logs: who did what, when

That is where authentication becomes a true architecture topic.

Decouple without pain: Strangler Fig and capability-based extraction

To extract without rewriting everything, the most robust pattern remains the Strangler Fig Pattern. The idea:

the monolith stays in production
a new service is built around a business capability
traffic is gradually redirected
the old piece is turned off once everything is stable

You extract by functional domain, not by technical layer.

Why identity becomes central

Identity is different from other capabilities. It touches:

all frontends
mobile
internal tools
extracted services

It is a mandatory pass-through. That is why externalizing identity is often:

an excellent first extraction
but rarely the very first thing to do

When to externalize auth and identity

The right triggers

Externalizing becomes relevant as soon as one of these signals appears:

multiple clients to support (web + mobile)
need for a unified identity (SSO, MFA)
the start of business decomposition
the desire to avoid each service re-implementing its own security

When it is not yet the right time

If:

a single frontend consumes the application
no extraction is planned in the mid term
auth is stable and not very complex

Then externalizing too early often adds more complexity than value.

Key strategy: a new identity for new consumers

Rather than migrating all legacy at once:

Set up the new Auth & Identity components
Route new consumers through this stack
Let the existing system live temporarily

Meanwhile, the monolith gradually becomes a resource server:

validate old legacy tokens + new JWT access tokens issued by the IdP
consume identity claims
keep legacy tables partially if needed

The most delicate point: user migration

"On-the-fly" migration

Accounts stay in the monolith at first. On the first login via the new stack:

the account is migrated or linked (mapping between the legacy id and the IdP id)
then permanently switched

Advantages:

no massive migration
rollback possible
low operational risk

The right implementation order

With hindsight, this order is very effective:

Clarify the identity model (user, admin, tenant)
Implement OAuth2 / OIDC
Externalize self-service flows
Switch a single channel (web or mobile)
Turn the monolith into a resource server
Gradually remove the old auth

Each step is measurable, reversible, and testable.

Conclusion - Identity as a foundation

Externalizing identity is not just a technical refactor.

It is:

laying a durable foundation
simplifying future extractions
making the architecture more readable
preparing the integration of other applications

Identity is not the first microservice to write. It is often the first one to think seriously about.