Why I chose Duende Identity Server

Every greenfield .NET system I have worked on in the last few years has had to answer the same question early: where does identity live. The wrong answer is expensive to undo, so it is worth being explicit about the trade-offs. Here is how I think about the decision and why Duende Identity Server has been the right pick more often than not.

ASP.NET Core Identity is a different abstraction

ASP.NET Core Identity is a user store and credential manager. It handles password hashing, two-factor flows, lockouts, and the user table. It is not an OIDC provider. People conflate the two because the templates wire them together, but the moment you have a second client (a mobile app, a SPA, a partner integration), you need an authorization server that issues tokens against a user store, not a user store on its own.

In practice I keep ASP.NET Core Identity around as the user store and put Duende in front of it. Identity owns the AspNetUsers table; Duende owns clients, scopes, grants, and token issuance. They compose cleanly, and the boundary matches how the two systems actually evolve.

The IdentityServer4 fork is a security posture problem

IdentityServer4 went end-of-life. Community forks exist, and they work, and people do run them in production. The honest reason I do not pick them is operational: when a CVE lands in a flow I depend on, I want a vendor with a support contract, security advisories, and a known patch cadence. Token issuance is not the place to be the first user of a community patch on a Saturday night.

If your context tolerates that risk profile, the fork is technically capable. For anything regulated, customer-facing, or financially significant, the support story is part of the security posture, not separate from it.

Managed providers are great until they aren’t

Auth0, Azure AD B2C, and Cognito remove a real burden. For a small team shipping a B2C product where the identity flows are standard, they are often the right answer. I have used them and would again. Two things eventually push me off them.

The first is cost at scale. Per-MAU pricing is fine until your active user count grows; then the bill grows linearly with success and the contract renegotiation is not fun. The second is the lock-in shape. Custom claims, custom flows, B2B tenant models, and long-lived refresh-token semantics tend to bend providers in ways that make migration off them hard later. Knowing exactly which OIDC behaviors you depend on is harder when those behaviors live in someone else’s UI.

Where Duende fits

Duende is the right call when at least one of these is true:

• You are in a regulated environment (finance, health, public sector) where data residency and full audit control of token issuance matter.
• You are building multi-tenant B2B with non-trivial federation: SAML for some tenants, OIDC for others, custom claim transformations per tenant.
• You need full OIDC control: custom grant types, fine-grained client policies, dynamic client registration, or tight integration with an existing user store.
• You expect identity to live in the system for a decade and want it on infrastructure you can patch on your own schedule.

In those contexts the operational ownership is a feature, not a tax. You run it, you patch it, you tune it.

The licensing reality

Duende is commercial above a revenue threshold. That is the part of the conversation I have learned to put on the table early, because it lands differently with finance and with engineering. The license cost is real, and at small scale it can feel disproportionate against an open-source fork. The way I frame it: you are paying for a maintained security boundary on the most sensitive surface in the system. Compared to the fully-loaded cost of an incident in token issuance, it is straightforward to justify, but it is a real line item and the team should know about it before code is written, not at renewal.

The short version

If the question is “user store or token server?”, the answer is both, and they are different jobs. If the question is “fork or managed or Duende?”, it is a posture question more than a technical one. For the systems I tend to build, Duende wins on control and on having a vendor I can call.