If you run IdentityServer4 in production, you have a decision that most teams keep deferring: IdentityServer4 stopped receiving updates at the end of 2022, the .NET runtimes it targets are out of support, and its successor, Duende IdentityServer, needs a paid license for most companies. “Alternative to Duende IdentityServer” is one of the searches that brings people to this site, so this is the page we would have wanted when we did our first migration: the five realistic options, what each one actually costs you in money and in engineering time, and the rule we use to pick.

Disclosure first: we migrate .NET teams off IdentityServer4 for a living, mostly to Duende, sometimes to OpenIddict, and we have talked more than one client out of a migration they didn’t need yet. We have a side, but it is not “always Duende”.

The five options in one table

Option	Licence cost	What changes in your code	Who runs it	Typical effort
Stay on IdentityServer4	Free (Apache 2.0)	Nothing	You, with no upstream fixes	Zero now, rising risk
Duende IdentityServer	Free Community Edition under the revenue threshold, otherwise a yearly licence per tier	Package and namespace swap, licence key, signing-key and data-schema changes	You, in-process in your ASP.NET Core app	Days to a few weeks
OpenIddict	Free (Apache 2.0)	Rewrite the server configuration layer; your ASP.NET Core Identity users and your clients stay	You, in-process	Weeks
Keycloak	Free (Apache 2.0)	Replace the server entirely; .NET apps become plain OIDC clients	You, as a separate Java service with its own database	Weeks, plus ongoing ops
Managed IdP (Microsoft Entra External ID, Auth0, Amazon Cognito)	Per monthly active user, with free tiers	Replace the server; re-implement custom flows inside the vendor’s extension model	The vendor	Weeks, plus user migration

The table hides the thing that decides most of these cases, so it gets its own section below: what is custom in your current IdentityServer4. A stock setup with a handful of clients and ASP.NET Core Identity behind it can go anywhere. A setup with custom grant types, a hand-written profile service, dynamic client registration or a bespoke consent flow is a different project for every row except Duende.

Option 1: staying on IdentityServer4

It still runs, and nothing forces you to move on a particular day. That is also the whole argument for staying, so be clear about what you are accepting.

IdentityServer4 has had no upstream updates since late 2022. Duende has shipped security fixes since then that IdentityServer4 never received, and the runtimes IdentityServer4 was built for (.NET Core 3.1, .NET 5) are themselves out of support, so you are either pinned to an unsupported runtime or running a community-patched fork. If a customer’s security questionnaire asks whether your token server is on a supported version, the honest answer is no.

Staying is defensible for an internal tool with a small, trusted client base and a planned decommission date. It is hard to defend for anything a customer logs into. If you stay, at least do the inventory step of our migration checklist now, so the eventual move is a scheduled project and not an incident response.

Option 2: Duende IdentityServer

Duende is IdentityServer4’s direct successor from the same authors. It is source-available, and for most companies it requires a paid licence in production. The licence is the reason this page exists, so let’s price it honestly.

The free Community Edition covers for-profit companies under a revenue and funding threshold and non-profits under a budget threshold; the exact numbers are on Duende’s pricing page and move over time, and we keep our own notes on them in the licensing section of the checklist. Above that, the paid tiers are priced per year by the number of client IDs and by feature set. The trap we hit on a real migration is that a straight port of a typical IdentityServer4 app silently uses features from the higher tiers, because Duende turns on automatic key management by default; we logged exactly that when we migrated the public quickstart.

What you get for the money is the shortest migration path by a wide margin: the packages swap, the namespaces change, your clients, scopes, resources, profile service and custom grants come across mostly as they are, and your users never notice. There is real work in the signing-key cutover and the operational-data schema, but it is days to a few weeks, not a rewrite. If the licence fits your budget, Duende is the lowest-risk answer and we recommend it more often than anything else on this page.

Choose Duende when you have custom grant types or a custom profile service, you have many clients, your users must not be touched, or the migration has to happen in one sprint. Think twice when the licence cost is a material fraction of what the product earns, or when you are only using the server as a thin front for ASP.NET Core Identity and have no customisation to carry.

Option 3: OpenIddict

OpenIddict is a free, Apache-licensed OpenID Connect server framework for ASP.NET Core. The word framework matters: it gives you the protocol engine, the token handling and the storage abstractions, and you write the endpoints and the flow logic around it. Many teams pair it with ASP.NET Core Identity for the user store, which is the same place most IdentityServer4 apps keep their users, so the user side of the migration is often untouched.

Compared with Duende, OpenIddict is less turnkey and has no licence. Its design is deliberately opinionated towards you owning the authorization endpoint, which is more code up front and more control afterwards. There is no in-process equivalent of Duende’s configuration-driven client and resource model; you map your IdentityServer4 clients into OpenIddict applications and scopes, and re-implement anything custom in your own endpoint code. Expect weeks rather than days, scaling with how much of IdentityServer4’s extensibility you used.

The payoff is a token server you fully own, with no annual licence to defend in a budget meeting and no tier to outgrow. For a product that is early, or a company that is small and expects to stay under its own control, OpenIddict is frequently the right long-term answer, and the “OpenIddict vs Duende” question is usually decided by one thing: how much custom identity logic you have to carry across.

Option 4: Keycloak

Keycloak is an open-source identity server from Red Hat, now a CNCF project. It runs as its own service, with its own database, an admin console, realms, user federation to LDAP and Active Directory, social login, and a long list of protocol features. Your .NET applications stop hosting a token server at all and become ordinary OpenID Connect clients and JWT-protected APIs, which is a clean architecture if you have several apps that should share identity.

The cost is operational. Keycloak is a Java application you deploy, size, back up, upgrade and secure, with its own release cadence and its own breaking changes between major versions. If your team already runs Java services or has a platform group, that is a known quantity. If you are a .NET shop with three engineers, you are adding a second runtime to the on-call rota for the one component that must never be down.

Moving to Keycloak also moves your users. Keycloak can import users and supports custom password-hash providers, so a bulk migration without a forced password reset is achievable, but it is a project in itself, and anything custom in your IdentityServer4 profile service becomes a Keycloak extension in Java. Choose Keycloak when you need an identity platform for a fleet of applications and have the operations capacity for it. Avoid it when the only thing you need is a token server for one .NET product.

Option 5: a managed identity provider

Microsoft Entra External ID, Auth0 by Okta and Amazon Cognito will run the whole thing for you, priced per monthly active user with generous free tiers at the low end. Nothing to patch, nothing to scale, a vendor security team, and compliance attestations you can attach to a questionnaire.

The trade is control and the bill’s shape. Per-MAU pricing is cheap for an internal tool and can become the largest line after hosting for a consumer product with many occasional users. Custom flows live inside the vendor’s extension model rather than in your code. Migrating users means either a bulk export with password hashes, which not every source and destination supports, or a lazy migration where each user is moved on their next login, which leaves you running both systems for months. And moving away later is a repeat of the same project in reverse.

Choose a managed IdP when identity is not a differentiator for you, the MAU maths works at your expected scale, and you would rather pay than operate. The companies we have seen regret it had either custom authorization logic that fought the vendor model, or a user base that grew into the pricing.

The decision rule we actually use

After enough of these, the choice comes down to three questions, in this order.

How much is custom? Count custom grant types, custom profile or claims logic, custom consent or login UI, dynamic clients and token customisation. If the answer is “a lot”, Duende is the only option that carries it across without a rewrite, and the licence is cheaper than the rewrite. If the answer is “nothing, it is a stock server in front of ASP.NET Core Identity”, every option is open.
Does the Duende licence fit? Check the Community Edition thresholds first; a surprising number of companies qualify. If you don’t, price the tier you would actually land on after the key-management check, not the tier on the front of the pricing page.
Who will run it? In-process (Duende, OpenIddict) is the least new operations. Keycloak is a new service. Managed is no service but a new vendor relationship. Match this to the team you have, not the team you plan to hire.

Applied honestly, that rule sends most established products to Duende, most early products to OpenIddict, multi-application estates with a platform team to Keycloak, and companies for whom identity is a commodity to a managed provider. Staying on IdentityServer4 is the answer only when there is a decommission date.

Where to go from here

If you want the step-by-step version for the Duende path, it is in the IdentityServer4 to Duende migration checklist, and the things that went wrong when we ran it on the public quickstart are in what actually breaks. A working Duende 8 server with an API and an MVC client, with the real code, is in the Duende IdentityServer example.

If you would rather have the decision made for your actual setup, our IdentityServer consulting starts with a one-hour session: bring the project, we go through the inventory above with you and tell you which row you are in, including when the answer is to stay put for now.