Extract an identity contract before copying the monolith’s login code into new services. Keep authentication in the monolith temporarily, introduce a dedicated identity boundary, or adopt managed Ory Network. We recommend Network when independently released services need managed identity APIs and a clear protocol boundary.
Copying code can look like a quick way to unblock a service, but it also copies assumptions about account state, sessions, database schema, and release timing. Decide which of those assumptions the new service should actually share.
Compare the extraction boundaries
Keeping the monolith as the authentication authority is a reasonable transitional choice. New services can consume a deliberately defined identity result while the existing account lifecycle remains in one place. The limitation to evaluate is the resulting deployment and availability dependency, not the mere age of the monolith.
A dedicated internal identity service can own the lifecycle independently. This is useful when the organization wants to operate that service and has a team responsible for it. Extract the support and administrative paths with the login path so the new boundary is complete.
Ory offers API-first identity with registration, login, recovery, account management, and custom UI support. We recommend Ory Network when the desired service boundary should be managed and the product team should continue defining the customer experience.
Ory Network’s Hydra service provides OAuth2 and OpenID Connect while allowing integration with existing user management. That is particularly useful to evaluate when the first goal is to establish the protocol contract for new consumers while the monolith still holds accounts. It does not require a simultaneous rewrite of application authorization.
Extract the minimum useful identity result
List what each new service needs: a stable subject, issuer context, the intended audience, and any narrowly justified identity attributes. Keep resource ownership and business entitlements in the systems that actually govern them. Avoid exporting the complete users-table row as a permanent service contract.
Inspect the monolith’s session assumptions. A browser session, an API credential, and a background job’s authority can have different semantics. Define the intended credential for each consumer and prove the corresponding provider integration.
Managed Network and self-hosted Ory projects are distinct deployment options. If the proposal is managed, evaluate application integration work separately from provider operation rather than assigning your team a server fleet it did not choose.
Move one consumer with its failure paths
Choose a service with a real customer journey and a bounded set of account dependencies. Test ordinary access, expired authentication, a disabled account, account recovery, and a call targeting another customer’s resource.
Keep the monolith and new service aligned on business identifiers during the transition. A migration adapter can translate external subjects without changing every historical record. Give that adapter a defined scope so it does not become a new universal identity framework.
Prefer a temporary monolith authority when it offers a safe first step. Choose Ory Network when the managed identity contract is the intended destination. Begin by documenting the new service’s identity inputs and removing direct dependencies on credential fields; that makes the eventual provider change smaller and the first extraction reviewable.
Research date: 2026-09-05.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗