Navigating Identity Management
The identity layer of your application is too critical to leave entirely in someone else's hands, whether that someone is a cloud vendor, an open-source maintainer, or a commercial provider. Most teams don't make this choice deliberately. They inherit it from an early decision made under time pressure. This guide is about making it deliberately, before that pressure arrives.
Most teams start with cloud
Cloud identity providers (Auth0, Azure AD B2C, Okta, AWS Cognito) exist because authentication is hard and most teams don't want to deal with it. That's a completely rational position. These services handle password storage, MFA flows, social login, token issuance, and session management so you don't have to. Early on, speed matters more than control, customization needs are minimal, and the cost of switching is still low. For a new product validating a market, that tradeoff often makes sense.
The friction shows up later.
Password hashes are not portable. Most cloud providers use proprietary formats: exporting user records doesn't mean exporting the ability to verify passwords. Your users will need to reset passwords on migration. For a product with tens of thousands of users, that's not a migration; it's a user experience incident. Some providers make this explicit in their contracts. Others don't mention it until you ask.
Data sovereignty is a related concern that starts abstract and becomes urgent. Where are your users' credentials actually stored, in which region, and under which legal jurisdiction? For regulated industries (healthcare, finance, government), these questions have compliance answers. For companies with EU users, they have GDPR answers. "Our cloud provider handles it" is not an answer that satisfies an auditor.
Customization limits tend to manifest as the product matures. Generic flows work until your business logic doesn't fit the template: a consent step with custom conditions, a token format with claims your downstream services expect, a login experience that needs to match your product's design system at a level the provider's themes don't support. At that point you're either maintaining workarounds, paying for enterprise tiers that expose more configuration, or building anyway, just on top of a system you don't fully control.
The on-premise middle ground
On-premise identity servers (Keycloak, WSO2 Identity Server, Authentik) solve the data control problem directly. Your user credentials are in your database, in your infrastructure, under your operational procedures. There is no export step, and no vendor decides the format your password hashes live in.
The tradeoff is maintenance. Running identity infrastructure means owning its security posture, its uptime, its upgrade path. When a critical vulnerability is disclosed in the JWT library underneath your identity server, you need to know about it and respond. When the framework it depends on releases a breaking change, you absorb the migration cost. These are manageable problems for teams with the operational maturity to handle them, and they're problems that exist with cloud providers too, just invisibly.
What on-premise doesn't solve is extensibility. The protocol implementation you choose determines how much you can adapt it to your specific needs, and that boundary becomes visible only when you hit it. Beyond that, the server you build on must be actively maintained and backed by a sustainable model: one where the maintenance calculus is visible and predictable before you commit to it.
There's a deeper risk too. Any product, however well-built, is maintained by people who eventually need to sustain the work differently. Pricing models change, maintainers move on, and support windows close. Identity infrastructure is a foundation: everything above it depends on it. Teams fare best when the identity layer is isolated enough that swapping implementations is mechanical, not architectural.
The attraction of in-house development
If you have a development team with the right expertise, building your own identity server is an option worth considering seriously. It gives you something neither cloud nor on-premise can fully match: complete ownership of the identity layer.
Your token format, claim structure, session behavior, and compliance requirements: none of it depends on a vendor's roadmap or a third-party template. When a compliance requirement demands a specific claim, you add it. When an enterprise client needs a custom login flow, you build it. The identity layer adapts to your product, not the other way around.
The honest tradeoff: this is genuinely difficult. OAuth 2.0 and OpenID Connect are specifications with hundreds of behavioral requirements, subtle edge cases, and security constraints that have caught experienced teams off guard. JWT handling alone involves key management, algorithm selection, and token validation nuances that are easy to get subtly wrong. A working integration test suite is not the same as a specification-correct implementation.
There's also ongoing responsibility. Security vulnerabilities in the authentication layer are incidents. Your team needs the expertise to recognize them, assess impact, and respond quickly. For teams that treat security as a core competency, this is ownership, not a burden. You're not dependent on a vendor's pricing decisions or a maintainer's roadmap. For teams that don't have that expertise, it's a liability that compounds over time.
Making in-house accessible
The difficulties described above are real, but they are not yours to solve from scratch. Protocol handling complexity (the hardest part of in-house development) can be delegated to a certified library. For instance, Abblix OIDC Server is an OIDF-certified .NET library you can take and use directly as the foundation for your own identity server. You skip the protocol complexity without giving up the ownership advantages.
The OpenID Foundation (OIDF) is the organization behind the OpenID Connect specification. It runs an independent conformance certification program: semi-automated test suites that verify implementations against every behavioral requirement across multiple profiles (Basic, Implicit, Hybrid, Dynamic, logout variants). Certification is public and comparable; any two libraries can be evaluated side by side on the OIDF site.
Abblix OIDC Server has passed the full conformance suite across all profiles with zero failures and zero skipped tests: 634 tests in total. Your team doesn't need years of protocol expertise to get it right. The library already got it right, and that result is independently verified: Regular Profiles and Logout Profiles.
Security responsibility is shared: the library handles the specification-level constraints; deployment, key management, and operations stay with your team. That's a manageable scope for a team with engineering discipline, far narrower than owning the full protocol stack.
What stays entirely yours: the data, the infrastructure, the customization, the integration with your business logic. All the advantages of in-house ownership, without the multi-year research project.
One question worth asking: which decision are we likely to regret making reactively in two years? The teams that made their identity choices deliberately were the ones helping others migrate when providers changed terms. The ones that deferred scrambled.