Abblix OIDC Server: An Alternative to IdentityServer4 and Duende

If you are running IdentityServer4 or Duende IdentityServer today and weighing your options, this guide is the map: why teams reach this decision, and what Abblix OIDC Server offers in that spot. See OpenIddict vs Duende IdentityServer vs Abblix OIDC Server for the feature grid, and the migration guide for the move itself.

Why teams look for an alternative

Two events send .NET teams back to the identity-library decision they thought they had settled.

IdentityServer4 reached end of life. Running it in production now means running protocol code that no longer receives security patches, which most security reviews will flag.

Its successor is licensed per deployment. Duende IdentityServer continues the IdentityServer4 codebase commercially, carrying more than a decade of lineage and the deepest operational toolkit in the ecosystem. For many teams that is a fair trade, and Duende is the natural fit. For others, the licensing model is the reason to keep looking.

OpenIddict is free and open source (Apache 2.0) at any scale. It is not OpenID Foundation certified - a deliberate policy, on the reasoning that certifying a framework does not certify a given deployment - which can still matter where formal conformance is required.

Abblix OIDC Server sits in the space those constraints define: a certified, self-hosted .NET library where every protocol feature is available in every tier, including the free one.

What Abblix offers in that spot

• Certified across all login and logout profiles. Abblix officially passed the OpenID Foundation conformance suite - Basic, Implicit, Hybrid, Config, Dynamic, Form Post, Third Party-Initiated, and all logout profiles - with zero failures in 600+ checks. The results are public and independently verifiable. This is the objective answer to "is it correct to spec?", the same criterion many teams used to pick IdentityServer4 over an uncertified library in the first place.
• Self-hosted, on keys only you hold. The library runs inside your perimeter, with no runtime call to a vendor. Its license enforcement is offline, and its code is readable, so you can see exactly what it checks.
• Every feature in every tier, the free one included. No protocol capability is locked behind a higher edition: the free tier is the full surface - CIBA, DPoP, full dynamic client registration, JARM, RAR, token exchange, per-client JWE, signed discovery metadata. The paid tiers change the license terms for commercial production use, not the capabilities.
• ASP.NET Core native. Every OIDC endpoint is a standard MVC controller in your own routing table and filter pipeline (or, starting from 2.4, Minimal API as an alternative). There is no parallel middleware world to learn or debug.
• Extension sized to the change. Small composable interfaces via widely known and adopted Composite and Decorator patterns, wired through standard .NET dependency injection. Changing one validation rule means implementing one focused interface, not copying a thousand-line class to adjust ten lines inside it.

The full engineering rationale - why the library was rewritten from scratch rather than forked - is in We Built Our Own OIDC Library. Why?.

Moving from IdentityServer is mechanical, not conceptual

The protocol concepts carry over. Clients, scopes, grants, and endpoints mean the same thing they did under IdentityServer, and Abblix issues standard JWTs - so resource servers keep validating tokens the same way, with no code change. The one piece of real work is persistence: you back Abblix's storage interfaces with your own database until the first-party Entity Framework Core and ASP.NET Identity stores land in Q4 2026.

Migrating from IdentityServer4 or Duende to Abblix maps the concepts and the persistence work.

The honest trade-offs

An alternative is only worth choosing with its costs on the table.

• The ecosystem is young. Downloads are in the thousands, not the millions, and there are no third-party admin tools or client libraries yet, so you bring your own admin UI and client-side stack. Abblix runs its own production identity provider on the library and the conformance results are public, but the community around it is still small.
• No first-party database stores yet. Persistence is your adapter code against the storage interfaces - a supported, permanent path; the first-party EF Core and ASP.NET Identity packages coming in Q4 2026 remove that code, they are not a prerequisite you are waiting on.
• No FAPI certification yet. FAPI matters only where a regulated program, such as open banking, makes it a gating requirement; there, Duende holds the certification today and Abblix does not, though FAPI 2.0 is on the roadmap. Standard OpenID Connect and OAuth 2.0 deployments do not need it.
• Documentation and samples are the smallest of the three, growing but still smaller. The getting-started and migration paths are covered, and GitHub Discussions is where the rest gets answered.

None of these is a reason to leave a working integration you are happy with. But each one is a reason to look closely before you make the choice.

Next steps

• Getting Started - a working OpenID Connect provider in an ASP.NET Core app in under an hour.
• Migrating from IdentityServer4 or Duende - the concept mapping and the persistence work.
• OpenIddict vs Duende IdentityServer vs Abblix OIDC Server - the full feature-by-feature comparison.
• Pricing - the tiers, with every protocol feature in each, the free one included.