Migrating from IdentityServer4 or Duende to Abblix OIDC Server

If you have decided to move a .NET identity provider off IdentityServer4 or Duende IdentityServer, this guide maps what the move actually touches. The short version: the protocol concepts carry over one to one, the token format does not change, and the real work is persistence.

For why teams make this move and what Abblix offers in that spot, see Abblix as an alternative to IdentityServer4 and Duende; for the feature-by-feature grid, the full comparison.

The concepts map one to one

Everything OAuth 2.0 and OpenID Connect defines means the same thing under Abblix that it did under IdentityServer. You are not learning a new model; you are pointing familiar concepts at different seams.

The vocabulary is very similar; what you rewrite is the wiring under each category.

What does not change

The token format. Abblix issues standard JWTs, so every relying party or resource server keeps validating them with no code change - issuer, signature, and claims are all standards-compliant. What you do check is claim contents: any non-standard claim your APIs authorize on (an idp, an auth_time, a custom profile claim) is yours to reproduce. Client-side validation is not part of the migration, which keeps the change contained to the server.

Signing keys, unless you carry them over. Abblix mints tokens with its own keys by default; you can import your existing ones through OidcOptions.SigningKeys, which takes full JWKs. Resource servers that resolve keys from the discovery document pick up the new set automatically; a service pinning a static key needs a config update only if you did not import the old keys.

Your user store. Abblix handles the protocol, not the user database. How you authenticate users - your SignInManager, your ASP.NET Identity tables, your external providers - stays where it is; the ASP.NET Identity integration guide shows the wiring, and Abblix reads the authenticated principal you already produce. What does move is the interaction glue: the consent, logout, and error pages that called IdentityServer's interaction service are re-pointed at Abblix's consent and end-session model.

The real work: persistence

This is the one place the move is genuinely code, not configuration. Where Duende ships Entity Framework Core stores, Abblix exposes storage interfaces you back with the database you already run.

• The client store is a plain read/write pair, IClientInfoProvider and IClientInfoManager. Back it with any database, relational or document; a relational client store is queryable, and the schema, migrations, and indexing are yours.
• Operational state - transient protocol data such as authorization codes - runs on any IDistributedCache the host configures. This is a real production requirement, not the in-memory default: across more than one node or a restart, that cache has to be shared and durable (Redis, SQL Server), or codes and rotation state are lost.
• Consent is not persisted by default - the built-in provider auto-grants every request, which suits trusted first-party clients. If you rely on remembered consent, you implement IUserConsentsProvider, its storage, and the consent screen yourself, and existing consent decisions do not migrate.
• A refresh-token inventory - if you need to enumerate or revoke active grants - is a stateful store you design. Access tokens are self-contained JWTs kept short-lived; refresh tokens can rotate (the default from 2.4) with server-side replay detection, and the inventory is what gives on-demand revocation when you need it.

In practice the client store plus the operational-cache wiring is 200 to 400 lines of adapter code against a database you already run; the client store alone is about a hundred, the size of Abblix's own. A consent provider and its screen, if you need remembered consent, are separate and larger. First-party Entity Framework Core and ASP.NET Identity stores are on the roadmap for Q4 2026; until they land, this adapter is the work.

Wiring it up

Abblix is assembled through standard .NET dependency injection. You register your storage implementations, add the OIDC services, and map the endpoints through the MVC adapter (or, from 2.4, Minimal API). There is no plugin system to learn: your implementations replace the defaults through ordinary DI registration, and every technique your team already has around .NET DI applies as-is. Abblix even extends the standard container with tools of its own, walked through in advanced dependency injection in .NET.

The step-by-step setup - services, endpoints, a working provider and client - is in the Getting Started guide. A migration is that same setup with your existing clients, scopes, and user store pointed at it.

What to expect

• Old tokens stop working. Access and refresh tokens minted by the previous server are not honored by Abblix. Clients holding a refresh token (mobile apps, offline_access grants, SPAs) get an invalid_grant on their next refresh and sign in again; if you collect consent, they re-consent too. Interactive users with a live SSO session cookie are carried by that cookie.
• Nothing is lost but the sign-in. Schedule the cutover as a user-visible event, like a key rotation, not a silent rollover.
• No client-side changes. Because the token format is standard, the applications that consume your tokens do not change.
• The persistence adapter is the critical path. It is a thin data-access shim against a database you already run, not new security logic - the protocol security stays in the library - but it is the piece to get right and test first.

Next steps

• Getting Started - the full setup, from services to endpoints.
• An Alternative to IdentityServer4 and Duende - why teams move and what Abblix offers.
• OpenIddict vs Duende IdentityServer vs Abblix OIDC Server - the feature-by-feature comparison.