IdentityServer4 was the go-to OpenID Connect and OAuth2 framework for .NET. The open-source version is no longer maintained. If you're still running it, you need a migration plan. I've done this migration multiple times. Here's what I've learned.
What happened to IdentityServer4?
IdentityServer4 was a free, open-source OpenID Connect and OAuth2 framework for ASP.NET Core. It was the standard way to build your own token service in .NET, handling authorization codes, access tokens, refresh tokens, and identity tokens according to the OAuth2 and OpenID Connect specifications.
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 no longer receives security patches.
If your .NET application still uses IdentityServer4, you're running on an unmaintained identity stack. That's a risk you can't explain away in a security audit.
Your three options
1 Duende IdentityServer
The direct successor. Same codebase, same API surface, same configuration model. 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.
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 is familiar with the IdentityServer4 configuration model
What it costs: Duende charges a license fee based on company revenue. Free for companies under $1M revenue. 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's actively maintained, free, and more modular than IdentityServer4. OpenIddict doesn't try to be a complete identity server out of the box. Instead, it gives you building blocks to implement exactly the OAuth2 and OpenID Connect flows you need.
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're 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 has a different configuration model. You'll rewrite your client registrations, grant type configuration, and token validation. But the OAuth2 and OpenID Connect protocols are the same, so your client applications won't need to change.
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. You don't manage keys, tokens, or session state. Microsoft handles security patches and 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're building a multi-tenant B2B SaaS application
Trade-off: You lose control over the authentication flow. Custom login pages, custom MFA, custom grant types: these become harder or impossible. If you need features outside what Azure Entra ID provides, you'll need to combine it with another solution.
What I typically see
Most .NET teams I work with end up in one of two situations:
- Simple token service. IdentityServer4 is used for a single SaaS application with a few OAuth2 clients (a web app, a mobile app, maybe an API). Migration to OpenIddict is usually the right call: lower cost, cleaner codebase, same functionality.
- Complex identity hub. IdentityServer4 sits at the center of a microservices architecture, federating with customer identity providers, supporting multiple grant types, maybe even federating with customer identity providers. Here, Duende IdentityServer is the pragmatic choice: minimal code changes, proven at scale.
In both cases, this is also the moment to add SCIM provisioning and proper SSO support. If you're already touching the identity layer, do it once and do it right.
Common mistakes in migration
- Migrating tokens during deployment. Don't. Issue new tokens. Old refresh tokens expire naturally; users log in again once.
- Keeping the old IdentityServer4 running "just in case". This creates two sources of truth for identity. Cut over cleanly.
- Not testing with real identity providers. OAuth2 and OpenID Connect have many optional features. Azure Entra ID, Auth0, and Google all behave slightly differently. Test with the actual IdPs your customers use.
- Ignoring key rotation. Your new token service needs proper signing key management from day one. Automate key rotation, don't hardcode keys.
My experience
I've 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 implement identity myself. This isn't theoretical knowledge.