IdentityServer4 was the go-to OpenID Connect and OAuth2 framework for .NET. The free open-source version is no longer maintained. If you are still running it, you need a migration plan.
I have done this migration several times. Some were simple token services. Others were sprawling identity hubs feeding a dozen services. This article covers why IdentityServer4 reached end of life, the three realistic replacements (Duende IdentityServer, OpenIddict, Azure Entra ID), and the mistakes that quietly break a migration while every test still passes.
What happened to IdentityServer4?
IdentityServer4 was a free, open-source OpenID Connect and OAuth2 framework for ASP.NET Core. For years it was the standard way to build your own token service in .NET. It issued authorization codes, access tokens, refresh tokens and identity tokens according to the OAuth2 and OpenID Connect specifications, and it did the job well.
In November 2020 the maintainers announced that IdentityServer4 would reach end of support. The project continued as Duende IdentityServer, a commercial product with a paid license. The free IdentityServer4 stopped receiving security patches.
So if your .NET application still uses IdentityServer4, you are running on an unmaintained identity stack. That is the kind of finding a security audit flags on the first page, and there is no good way to explain it away.
What are your three options?
Three replacements are worth taking seriously. Which one fits depends on how complex your current setup is, whether you still want to run your own token service, and how much control you are willing to hand over.
1. Duende IdentityServer
The direct successor. It shares the codebase, the API surface and the configuration model you already know. If your IdentityServer4 setup is complex, with custom grants, custom token validation, or federation with multiple upstream identity providers, Duende is the lowest-risk migration you can make.
When to choose this:
- You have a complex identity setup with custom grant types or token services.
- You need full control over the OpenID Connect / OAuth2 pipeline.
- You federate with multiple identity providers (Azure Entra ID, Auth0, ADFS).
- Your team already knows the IdentityServer4 configuration model.
What it costs: Duende charges a license fee based on company revenue. Companies under $1M revenue pay nothing. The code migration itself is straightforward, mostly namespace changes and NuGet package updates.
2. OpenIddict
An open-source OpenID Connect server framework for ASP.NET Core. It is actively maintained, free, and more modular than IdentityServer4 ever was. OpenIddict does not ship as a complete identity server out of the box. It hands you building blocks, and you assemble the exact OAuth2 and OpenID Connect flows your application needs.
When to choose this:
- You want to stay open-source and avoid license fees.
- Your OAuth2 / OpenID Connect requirements are well defined (you know which grant types you need).
- You are comfortable writing more of the identity plumbing yourself.
- You want tight integration with Entity Framework Core for token and client storage.
Migration effort: Higher than Duende. OpenIddict uses a different configuration model, so you will rewrite your client registrations, grant type configuration and token validation. The good news: the OAuth2 and OpenID Connect protocols stay identical, so your client applications keep working untouched.
3. Azure Entra ID (formerly Azure AD)
Stop running your own token service entirely. Azure Entra ID handles OpenID Connect, OAuth2 and SCIM provisioning as a managed service. No keys, tokens or session state to babysit. Microsoft owns the security patches and the protocol compliance.
When to choose this:
- Your customers are primarily on Microsoft 365 / Azure.
- You want to stop managing identity infrastructure.
- You need SCIM user provisioning without building it yourself.
- You are building a multi-tenant B2B SaaS application.
Trade-off: you give up control over the authentication flow. Custom login pages, custom MFA and custom grant types get harder, sometimes impossible. Need something Azure Entra ID does not offer? Then you are back to bolting a second solution onto it.
How do the three compare?
Here is a quick side-by-side to anchor the decision before you dig into the details.
| Option | Cost | Migration effort | Best fit |
|---|---|---|---|
| Duende IdentityServer | License fee (free under $1M revenue) | Low (namespace + package changes) | Complex identity hubs, custom grants, federation |
| OpenIddict | Free, open source | Medium (new configuration model) | Well-defined OAuth2 needs, EF Core storage |
| Azure Entra ID | Per-user, managed service | Varies (re-platforming, less custom code) | Microsoft-centric B2B SaaS, no infra to run |
What do real .NET teams usually pick?
Most .NET teams I work with land in one of two situations.
- Simple token service. IdentityServer4 serves a single SaaS application with a handful of OAuth2 clients (a web app, a mobile app, maybe an API). OpenIddict is usually the right call here. It costs nothing, leaves you with a cleaner codebase, and does everything the old setup did.
- Complex identity hub. IdentityServer4 sits at the center of a microservices architecture, federating with customer identity providers and supporting multiple grant types. Duende IdentityServer is the pragmatic choice. Minimal code changes, and it is proven at scale.
Either way, this is the moment to add SCIM provisioning and proper SSO support. You are already in the identity layer with the hood up. Do it once and do it properly.
Which migration mistakes break things quietly?
- Migrating tokens during deployment. Do not. Issue new tokens instead. Old refresh tokens expire on their own, and users sign in once more. That is the whole cost.
- Keeping the old IdentityServer4 running "just in case". Now you have two sources of truth for identity, and they will drift. Cut over cleanly.
- Skipping tests against real identity providers. OAuth2 and OpenID Connect carry a lot of optional behaviour. Azure Entra ID, Auth0 and Google each behave a little differently in practice. Test with the actual IdPs your customers use.
- Ignoring key rotation. Your new token service needs proper signing key management from day one. Automate the rotation. Keep keys out of source control.
The protocols stay the same across all three options, so your client applications barely notice the switch. The risk lives in your server configuration. The wire is fine.
What does this look like in practice?
I have built and migrated multiple identity implementations in .NET:
- IdentityServer4 implementations from scratch.
- Migrations from IdentityServer4 to Duende IdentityServer.
- Migrations from IdentityServer4 to OpenIddict.
- Azure Entra ID integrations for B2B SaaS applications.
- SCIM 2.0 provisioning endpoints for enterprise customers.
- Custom OAuth2 / OpenID Connect token services.
I also run my own SaaS products (Invullen.nl, Factuur-Assist.nl), where I build the identity layer myself. So none of this is theory. It is what I do on my own production systems.
Still running IdentityServer4? Every month it sits there unpatched is a month of accumulating risk. Which of the three paths fits the setup you have today?
