Abblix OIDC Server vs Duende IdentityServer vs OpenIddict
Three teams looked at the same problem (a correct, standards-faithful OpenID Connect and OAuth 2.0 server for .NET) and answered it three different ways. Duende IdentityServer, tracing back to the IdentityServer project that pioneered self-hosted OpenID Connect on .NET, carries more than a decade of production lineage and the deepest operational toolkit in the ecosystem. OpenIddict gives the .NET world a genuinely free, Apache-licensed server that runs everywhere from .NET Framework to .NET 10. Both are the product of years of careful engineering, and a great many teams are well served by them.
This page compares these established, well-known products with a different way of looking at the same problem: Abblix's. Where the others grew into broader platforms (bundled stores and client libraries, and in Duende's case server-side sessions and admin tooling), Abblix concentrates on a broad set of modern OAuth/OIDC protocol extensions in .NET, behind an isolated core you extend through standard .NET dependency injection: registering, decorating, or replacing its services.
That is a bring-your-own (BYO) philosophy, and it runs through most of the design and architectural decisions Abblix OIDC Server rests on: persistence, sessions, consent, UI, and the client side are all yours to supply behind the library's interfaces. BYO-database is the clearest case: the server ships no store of its own, and every storage seam takes whatever database you choose (a relational store, a document store, or any distributed cache) behind a narrow interface. Abblix's own identity provider runs this model in production on PostgreSQL and Redis, so the approach is proven at least at the vendor's own production scale.
Like any philosophy it trades something away: the operational scaffolding the others hand you, you assemble yourself. For a large, mature organization the gap is smaller than it looks, but it is not zero: such a team already runs its own data platforms under its own rules for where each class of data may live, and often prefers its own store behind the interfaces regardless. The adapter code, the schema, and (if needed) a queryable grant store are still yours to build and own. A ready-made store earns its keep fastest early on, when you are standing up a prototype, an evaluation, or a first deployment with no persistence code to write.
Part of that focus is conviction; part is plain arithmetic. Abblix is the youngest product here, and a decade of ecosystem evolution does not compress into two years, so we deliberately choose what ships first. The protocol layer, certified across all seven OP and four logout profiles, won out; the periphery follows in priority order: some of it from our own roadmap, the rest each integrator builds for himself on the library's public seams. The rest of this page maps exactly where that trade lands, feature by feature.
We make one of the three products compared here, so we hold ourselves to a simple rule: every claim links to product source or a public registry, not a marketing page. Found something wrong or out of date? Open an issue with a pointer to the code and we will correct it.
Versions compared (shipped releases, verified 2026-07-06): Abblix OIDC Server 2.3 (2026-06-09), Duende IdentityServer 8.0.2 (2026-06-16), OpenIddict 7.5.0 (2026-04-22). A capability that exists only on an unreleased branch is marked as such and not credited to the shipped product; Abblix's own roadmap is tracked this way systematically, while a competitor's unreleased branch is mentioned only where we happened to verify it; the absence of a forward note says nothing about their plans.
At a glance
| Abblix OIDC Server | Duende IdentityServer | OpenIddict | |
|---|---|---|---|
| Model | Source-available, commercial | Source-available, commercial | Open source (Apache 2.0) |
| First public release | 2024 | 2021 (announced 2020; lineage to 2013 IdentityServer) | 2015 |
| Free production use | Non-commercial projects only (2 clients, 1 issuer) | Free dev/test; production needs a license | Unconditionally free |
| Feature gating by license | None: every feature in every tier, including free | Some protocol features are edition-specific (see Duende's editions) | None |
| Platform | .NET 8/9/10, ASP.NET Core | .NET 10 (v8); .NET 8/9 (v7.x), ASP.NET Core | .NET Framework 4.6.2+ and .NET 8/9/10, ASP.NET Core and OWIN |
| OpenID certification | No FAPI certification; OpenID-certified v1 + v2 across all 7 OP profiles + all 4 logout profiles | FAPI 2.0 SP (Final) certified for v7.3, August 2025; OpenID-certified v5/v6/v7 across 5 OP profiles + all 4 logout profiles | Not certified (deliberate policy) |
| First-party database stores | None: host-implemented behind storage interfaces | EF Core | EF Core, EF 6, MongoDB |
| Client-side library | None | Certified open-source OidcClient + token management; commercial BFF | Full free client stack, 111-provider gallery |
| NuGet downloads, lifetime* | ~6.6K (since 2024) | ~25.4M (since 2020) | ~25.9M Server (listed on NuGet since 2018; project since 2015) |
| Team | 1 primary developer (2-person team) | Multi-person team (no public count to pin a number to) | 1 primary maintainer among 70 lifetime contributors |
* Lifetime totals over very different product ages: read as adoption scale, not a like-for-like popularity measure; every vendor's total also includes downloads pulled transitively by other packages (most visibly OpenIddict's Abstractions at ~37.8M, but true of all three).
Protocol coverage
All three implement the OAuth 2.0 / OIDC core: authorization code + PKCE, client credentials, refresh tokens, discovery, JWKS, userinfo, introspection (RFC 7662), revocation (RFC 7009), end-session, device flow (RFC 8628), PAR (RFC 9126), resource indicators (RFC 8707), mTLS (RFC 8705), and the iss response parameter (RFC 9207). The differences concentrate in the newer extensions; whether they matter depends on your compliance targets (FAPI 2.0, open banking, eIDAS) and integration scenarios.
| Capability | Abblix 2.3 | Duende 8.0 | OpenIddict 7.5 |
|---|---|---|---|
| CIBA (backchannel auth) | ✅ poll + ping + push | ⚠️ poll only | ❌ |
| DPoP (RFC 9449) | ✅ | ✅ | ❌ |
| Token exchange (RFC 8693) | ✅ first-party grant | ⚠️ via extension point (no first-party grant) ¹ | ✅ first-party (since 7.0) |
| JWT-bearer grant (RFC 7523) | ✅ | ⚠️ client auth only (no authorization grant) | ⚠️ via custom flow wiring |
| Dynamic Client Registration | ✅ RFC 7591 + full RFC 7592 management | ⚠️ RFC 7591 only | ⚠️ programmatic API only (no DCR endpoint) |
| JARM (JWT-secured responses) | ✅ | ❌ | ❌ |
| Rich Authorization Requests (RFC 9396) | ✅ | ❌ | ❌ |
| JWT introspection responses (RFC 9701) | ✅ | ✅ | ❌ |
| Request objects (JAR, RFC 9101) | ✅ by value + by reference, JWE supported | ⚠️ by value; request_uri off by default | ❌ signed request objects rejected (PAR carries plain parameters only) |
| Pairwise subject identifiers | ✅ | ❌ | ❌ |
claims request parameter (OIDC 5.5) | ✅ | ❌ | ❌ (claims_parameter_supported:false) |
client_secret_jwt | ✅ | ❌ | ❌ |
| ID token / userinfo encryption (JWE) | ✅ per-client ⁴ | ❌ | ⚠️ access tokens JWE by default; not per-client ID-token JWE |
| OIDC Session Management spec + front/back-channel logout | ✅ all three ² | ✅ all three | ❌ RP-initiated logout only |
oauth-authorization-server metadata suffix (RFC 8414 §3) | ⚠️ served at openid-configuration; the oauth-authorization-server suffix is added in 2.4 ³ | ✅ | ✅ |
response_type=none (authorize a grant, return no code or token) | ❌; opt-in support unreleased (2.4) | ❌ | ✅ |
| SAML 2.0 IdP | ❌ | ✅ v8, opt-in | ❌ (third-party add-on) |
| FAPI 2.0 | ⚠️ building blocks conformance-suite-tested; named enforcement profile unreleased (2.4); no certification | ✅ FAPI 2.0 SP (Final) certified for v7.3 (August 2025; the compared 8.0.2 not yet listed), with self-assessment tooling | ⚠️ has PAR, mTLS; no JAR, no DPoP; no certification |
¹ "Via extension point" means Duende ships no built-in token-exchange grant. It exposes a generic custom-grant hook (the IExtensionGrantValidator interface) through which the host implements RFC 8693 itself (Duende's own BFF host ships a sample TokenExchangeGrantValidator that does exactly this). There the exchange wiring is host code by design; a first-party grant (Abblix, OpenIddict) ships that wiring ready-made, while the trust policy itself, which subject and actor tokens to accept and what to issue, stays yours to configure in all three.
² The ✅ marks the OIDC Session Management + front/back-channel logout protocol. An admin-queryable, remotely revocable server-side session store is a separate operational capability, ready-made only in Duende; Abblix exposes session access behind IAuthSessionService for the host to back with its own store (see Storage).
³ RFC 8414 §3 lets a server publish its Authorization Server Metadata under either the oauth-authorization-server or the openid-configuration well-known suffix. Abblix serves a full RFC 8414 document (including the optional §2.1 signed metadata) at openid-configuration; Duende and OpenIddict also expose the oauth-authorization-server suffix, while shipped Abblix 2.3 does not, so on 2.3 a client that queries only oauth-authorization-server reaches the two competitors, not Abblix. The 2.4 development branch serves the same document at the oauth-authorization-server suffix as well.
⁴ Abblix's per-client JWE covers RSA key transport, AES-GCM key wrap, and direct keys for key management; the AES-KW, ECDH-ES, and PBES2 families are not implemented (see JWT foundations).
Sources: every mark above is pinned to the compared versions and checkable in the Abblix 2.3, Duende 8.0.2, and OpenIddict 7.5.0 source trees. Discovery-advertised capabilities (grant types, response modes, claims_parameter_supported, subject_types_supported, request_uri_parameter_supported) can also be read directly from each server's .well-known/openid-configuration.
A few caveats on Abblix's protocol support. Several capabilities (the FAPI 2.0 named security profile, the per-client PAR requirement, the Minimal API adapter, the opt-in none response type, and further conformance hardening) exist only on the development branch targeted at v2.4, not in the shipped 2.3. client_secret_jwt requires client secrets stored with their raw value, since HMAC verification needs it: a deployment precondition to plan for. Shipped 2.3 serves its RFC 8414 metadata only at the openid-configuration suffix (footnote ³ above). On FAPI specifically, Duende is ahead today: it holds the only OIDF FAPI certification among the three (FAPI 2.0 Security Profile, Final, for v7.3) and ships self-assessment tooling. And no product of the three implements EdDSA signing, while post-quantum ML-DSA exists only on OpenIddict's unreleased development branch.
Licensing model
OpenIddict is open source under Apache 2.0: modify and redistribute freely, with an express patent grant and no license-enforcement code. Support is sponsor-oriented.
Duende IdentityServer is a commercial, source-available product licensed by edition, and some protocol features are tied to a specific edition. For editions, included limits, and terms, consult Duende's own licensing pages.
Abblix OIDC Server is a commercial, source-available product licensed by quantity (client and issuer count), with every protocol feature present in every tier including the free one and no per-feature gating anywhere in the code. License validation is fully offline against an embedded certificate, transmits nothing to the vendor, and the entire enforcement path is readable in the public repository. The con of this model: the free tier is non-commercial only (2 clients, 1 issuer), so a commercial team pays from its first production use.
Architecture
Abblix adopts a hexagonal (ports-and-adapters) design: a protocol core isolated behind ~140 public interfaces, a thin MVC adapter (with a Minimal API adapter shipping in 2.4), which you customize the way any ASP.NET Core app is: implement one of its interfaces, decorate an existing one, or compose a family of them through standard DI plus a small Abblix-supplied composite/decorator toolkit (TryAdd everywhere). The built-in pipeline families (grant handlers, authenticators, context validators) fold into composites at AddOidcCore, and a single built-in step can be edited through the DI container; the extensibility sections below detail how the granularity and effort compare across all three.
Duende is service-oriented, running its own middleware/router (neither MVC nor endpoint routing), with ~140 interfaces, dozens of builder extension methods, and a structured events subsystem.
OpenIddict is an event/handler pipeline of ~270 ordered handler descriptors that can be individually removed or reordered, the finest-grained request-level control of the three. Its server core has zero ASP.NET dependencies and runs on both ASP.NET Core and OWIN, the only option for classic .NET Framework hosts.
None of the three offers first-class multi-tenancy; all three can derive the issuer from the incoming request, but only Duende and Abblix route issuer resolution through a replaceable service (IIssuerNameService / IIssuerProvider) that a multi-tenant host can implement. External/social login brokering is delegated to ASP.NET Core authentication handlers in all three; Duende additionally offers store-backed dynamic external providers.
JWT foundations
Here Abblix parts company with both competitors: Duende and OpenIddict both build on Microsoft's Microsoft.IdentityModel stack (the JsonWebTokenHandler and its SecurityKey/SigningCredentials model) to create and validate every JWT. Abblix does not: Abblix.Jwt, the library Oidc.Server is built on, implements JWS (RFC 7515), JWE (RFC 7516), and JWA (RFC 7518) itself, on .NET's cryptographic primitives and System.Text.Json.Nodes.
The cryptography itself is common ground: signing, verification, and encryption run on .NET's System.Security.Cryptography in all three products; Abblix.Jwt calls those BCL classes exactly as Microsoft.IdentityModel does under Duende and OpenIddict, and nobody hand-rolls the algorithm math. The layer Abblix owns is the JOSE assembly above the primitives, and that layer is no formality: historically, JWT attacks live precisely there (algorithm confusion, none acceptance, embedded-key trust, crit and typ mishandling). Abblix treats it as security code and hardens it in the shipped source: byte-exact alg allow-listing against a closed set, RFC 7515 crit handling that rejects unknown extensions by default, RFC 8725 typ pinning, and a hard split between embedded-key and issuer-key trust models, the same duties Microsoft.IdentityModel enforces in its own handler; owning the layer means owning those duties, not that the incumbent skips them. Owning the layer also means owning its upkeep: a defect here (algorithm confusion, none acceptance, crit/typ mishandling) is Abblix's to find, patch, and ship itself, where the competitors ride Microsoft's servicing cadence (well-resourced, though not advisory-free). What bounds Abblix's exposure is the surface it covers: a closed, explicitly-hardened JOSE assembly (the checks just listed) over .NET's own crypto primitives, exercised daily in the vendor's own production identity provider.
That payoff sits in the API. First, the one that matters most in daily use: a JWT is modeled directly as System.Text.Json.Nodes, so a structured claim like cnf, authorization_details, or the OIDC claims request stays live JSON you read as JSON; the Microsoft handler can also read payload values directly (GetPayloadValue<T>), but the ClaimsPrincipal projection the Microsoft stack produces represents such a claim as a Claim whose value is a JSON string. Beyond that, keys are resolved and issuer and audience checked through async delegates, so per-tenant key lookup and on-demand JWKS retrieval stay non-blocking, and validation returns the same Result type the rest of the library uses, so token errors flow through one error-handling path. On signing algorithms the two stacks are level: the usual RSA, ECDSA, and HMAC families on both sides. On JWE key management the two stacks cover different subsets: Abblix implements RSA key transport, AES-GCM key wrap, and direct keys (a deliberate native-.NET-crypto-only policy) and currently lacks the AES-KW and ECDH-ES families the Microsoft stack carries; the Microsoft stack in turn has no AES-GCM key wrap, and PBES2 is absent on both sides.
Reshaping and extending
These three bend to a customer- or regulator-specific requirement in different ways, and the real split is between reshaping an existing endpoint and adding a new one. Reshaping is the everyday case: all three do it, but at different granularity and different depth of code you must learn first. For decorating or replacing a whole interface, Abblix's per-change action is a single registration through ordinary ASP.NET Core DI. Editing a step inside a built-in pipeline is a single line via the Decompose<T>() cursor on the 2.4 branch; on shipped 2.3 that same edit is advanced Microsoft-DI work, comparable in effort to replacing a Duende service. Duende works at the service level: intervene through documented custom-service replacements and its events subsystem, idiomatic hooks at defined points within Duende's own service model. OpenIddict offers the finest control for the most immersion: every step is one of ~270 ordered handler descriptors you can remove, reorder, or insert new handlers between; that is maximum precision, once you have learned the handler-pipeline model. By granularity the order is OpenIddict, then Abblix, then Duende; how much each asks you to learn is a separate axis.
Adding a brand-new endpoint is where they genuinely differ, and it traces to how each product routes. Duende, running its own router, requires a new protocol endpoint (such as a regulator-mandated endpoint that has to behave like a built-in) to be registered in its server pipeline, where it runs under the same conventions as the built-ins. Neither OpenIddict nor Abblix has that concept: in both, a new endpoint is an ordinary application route calling into the library. The difference is what surrounds that route. Abblix's own endpoints are themselves ordinary MVC (and, from 2.4, Minimal API) routes with no server router underneath, so a custom route sits beside them as an equal and consumes the same services they do through DI: client authentication, discovery configuration, error shaping. OpenIddict dispatches its built-in endpoint types through its own host-integration handlers (a closed enum: URIs relocate, the set does not), the same owned dispatch that buys its OWIN and .NET Framework reach.
Two more axes are environmental rather than behavioral. Endpoint paths are freely relocatable in Abblix (tokenized route templates resolved from configuration in the MVC adapter, each path plus the shared base and .well-known prefixes, or an OidcRouteOptions object in the 2.4 Minimal API adapter) and in OpenIddict (SetXEndpointUris on the server builder); both surface the relocated paths in the discovery document automatically. Duende serves its endpoints at fixed protocol paths under a host-set base (toggled on or off, not individually relocated), with a discovery document that reflects whatever is served and a replaceable generator behind it. And when a product's extension points run out, its license sets the last resort: OpenIddict (Apache 2.0) forks freely, while Abblix and Duende are source-available: readable and modifiable within their license terms.
The learning curve for extensibility
The workable way to compare how hard each is to customize is not to score "difficulty" in a vacuum: that number would be invented. Split the entry threshold into two parts: the domain knowledge every OIDC server demands (OAuth 2.0 and OpenID Connect themselves, identical everywhere) and the product-specific extension model each one asks you to learn on top of it. The first is a constant; the second is what actually separates the three, so the objective comparison is how much you must learn beyond the protocol you already had to know. (Learning, not build volume: on that second axis the ready-made stores, UI, and client stacks of the other two spare you the work Abblix leaves to the host; see Storage and Developer experience.)
Each product also hands you a different unit to reason in, and a different amount of its own machinery to learn before you can use it:
| Product | The unit you extend | What you learn beyond OAuth/OIDC |
|---|---|---|
| Duende IdentityServer | A domain service: a named interface owning one area of behavior | Which documented service to replace, plus its events subsystem (the best-documented model of the three) |
| OpenIddict | A pipeline handler: one of ~270 ordered descriptors | The handler-pipeline model itself: ordering, event flow, how handlers compose (the largest model, and the price of its finest-grained control) |
| Abblix OIDC Server | A domain rule or feature: smaller than a service, still in protocol vocabulary | How its rule families compose: one rule registered before AddOidcCore (2.3); editing an existing step in place is a one-line Decompose<T>() cursor on the 2.4 branch, advanced Microsoft-DI work on shipped 2.3 |
Read down the last column and the axis is clear: the domain knowledge is fixed; the products differ in how much of their own architecture they put between you and a change. That is the axis Abblix is built to minimize: its aim is that extending the server leans on the dependency injection a .NET developer already uses and on protocol vocabulary, not on a model of the library's internals. What stays genuinely product-specific is real but small: learning which of the ~140 interfaces owns the behavior you need (a generated API reference and an extension-points map both help locate it, though the guided, narrative documentation is thinner than Duende's), plus the single composition rule the table names above.
Duende gives you a dedicated hook at each point it has anticipated (ICustomAuthorizeRequestValidator, to fold extra rules into the authorization request, is one of many across its documented services and events), and where no ready-made hook fits, you replace or decorate the domain service that owns that area. Abblix decomposes the same behavior one level finer: the validators and processors a service would own are themselves a composed family of individual rules (the Composite and Decorator patterns applied to the pipeline), so a change can be a single rule inserted, swapped, or wrapped, one level below the whole service that Duende's replace-or-decorate operates on. That finer unit is what the somewhat larger learning curve buys: more points to intervene without replacing a bigger component, in exchange for one model to learn: how families compose.
A few qualifiers bound the reading. The threshold inverts with depth: Abblix's low entry point is for reshaping in the common case, while the finest step-level control sits at the far end of OpenIddict's larger model. And it stays a qualitative reading: an entry threshold depends on the reader's background, so what compares cleanly is the direction and the amount of new material.
Storage, persistence and operations
This is the sharpest architectural divide of the three: not whether a database can sit behind the server, but who designs it.
Duende and OpenIddict ship ready-made persistence: their store packages (EF Core; OpenIddict also EF6 and MongoDB) give durable, queryable, individually revocable grants and tokens from day one, with two different schema philosophies: Duende consolidates grant kinds into one table queried by envelope fields (subject, client, session, type), while OpenIddict spreads them across four relational tables with subclassable entities (ReplaceDefaultEntities<TKey>()).
Abblix's intended model is BYO-database behind the interfaces. Every storage concern sits behind a replaceable seam: IEntityStorage (a single key-value contract for all operational state), IClientInfoProvider/IClientInfoManager for clients, IUserInfoProvider for identity data, IUserConsentsProvider for consent. Abblix's own hosted identity provider, known as Abblix Account, runs exactly this way: user and identity data in PostgreSQL queried through Dapper behind IUserInfoProvider, with Redis carrying protocol state. The trade cuts both ways: you design and implement the database yourself (work the ready-made stores spare you, but work that scales with ambition, from near-zero for cache-backed operational state through a small durable client store to a real relational grant layer if you want one), in exchange for full control of your schema, retention and indexing rules, and data layer, with no vendor tables or migrations in your database. User data works this way in all three products: none ships a user store; Abblix extends the same model to its entire server configuration.
Out of the box, Abblix ships no database store package: the host is responsible for persistence by design. All operational state (codes, PAR/CIBA/device requests, revocation marks) lives as expiring entries in whatever IDistributedCache implementation the host registers behind the built-in IEntityStorage adapter (in-memory for dev, Redis, the SQL Server distributed cache, or any other backend), serialized using protobuf. Zero-database deployment is trivial, no cleanup job is ever needed, and even the default path becomes durable if the chosen backend is persistent. The remaining trade is the flip side of stateless tokens: out of the box there is no queryable inventory of outstanding grants or refresh tokens (the default keeps only per-token revocation status, not a positive list), so token-level bulk or forensic operations such as listing every active token are not built in, where Duende and OpenIddict ship them in their grant store. The gap is enumeration, not revocation: a token you know about is revocable through the standard revocation endpoint today, and the exposure of what cannot be enumerated is capped by short access-token lifetimes. Nothing blocks building the full inventory: a host that needs it records issued tokens at the IRefreshTokenService/IAccessTokenService seam and revokes through the same status-check path. That is genuine build-out: a queryable, revocation-synced store, in exchange for the stateless model that keeps Abblix's zero-database default.
On token formats, Duende and OpenIddict both support opaque reference access tokens alongside JWT (OpenIddict adds an ASP.NET Data Protection binary format), while Abblix issues self-contained JWTs only, a deliberate stateless choice (RFC 9068 standardizes the JWT access-token format; RFC 6749 leaves it open). Opaque tokens trade stateless validation for instant central revocation and a listable token inventory, paid for with a server-side store consulted on every validation, the stateful scaffolding Abblix's BYO model leaves to the host. Signing-key lifecycle is Duende's clearest operational win out of the box: it is the only one with automatic key generation, 90-day rotation, propagation, and Data-Protection-encrypted storage on by default. Abblix brings no timer-based auto-rotation but resolves keys through a replaceable IAuthServiceKeysProvider seam and publishes multiple keys in JWKS at once, so overlapping manual rotation and a host-supplied dynamic/rotating key provider are both allowed (its own docs recommend the latter for production); OpenIddict likewise registers multiple signing credentials and publishes them all in JWKS, so overlapping rotation works there too, but it resolves them from static host configuration, so rotating means a configuration update and redeploy rather than swapping a replaceable runtime provider.
Queryable, remotely revocable server-side sessions ship ready-made only in Duende; Abblix routes session access through a replaceable IAuthSessionService abstraction whose default adapter binds to the ASP.NET Core cookie but behind which a host can implement its own store, and OpenIddict delegates sessions to the cookie, where ASP.NET Core's standard server-side ticket store can apply. Remembered consent ships ready-made in OpenIddict (permanent authorizations) and Duende (consent store); Abblix exposes it as a replaceable IUserConsentsProvider with an auto-granting default, so persistent consent is a host implementation, the same BYO pattern as its other storage seams. ASP.NET Core Identity integration ships only in Duende as a first-party package, OpenIddict pairs with Identity in every sample, and Abblix has no first-party Identity package, though its docs carry an integration guide with a runnable sample. Finally, on observability, Duende instruments its endpoints with ActivitySource tracing (OpenTelemetry-ready) on top of its events subsystem, while Abblix and OpenIddict expose standard ILogger logging only: no built-in traces or metrics.
Security posture
Much of day-to-day security (PKCE requirements, refresh-token rotation, HTTPS enforcement) can be configured to identical behavior in all three products, so settings are not compared here; what remains are the behavioral differences no setting changes. A replayed authorization code is rejected by all three (codes are single-use); Abblix and OpenIddict additionally revoke the tokens already issued from that code (RFC 6749 §4.1.2). On refresh-token reuse, OpenIddict responds the strongest: replaying a redeemed token revokes the entire chain. With per-client rotation enabled (a config switch, not the 2.3 default; see below), shipped Abblix 2.3 invalidates every rotated-out token and rejects its replay, but tracks no lineage, so, exactly as Duende does with one-time-use tokens configured, it treats the replay as an ordinary revoked-token rejection without sweeping the family, and the still-active token minted from the stolen copy survives until its own expiry. The upcoming Abblix 2.4 adds a per-grant family claim so the same replay revokes the whole refresh-token family, the rotation-with-lineage model OpenIddict implements (RFC 9700 §4.14.2). One more difference no setting changes: what you can enumerate and revoke during an incident. Duende's persisted grants and server-side sessions and OpenIddict's database-backed tokens and authorizations are listable and revocable out of the box, while Abblix's stateless tokens leave that inventory to the host (individually known tokens stay revocable out of the box, and what cannot be enumerated expires on its short lifetime; see Storage).
The shipped defaults still differ, and they show where each product leans by design. Abblix requires PKCE per client and rejects the plain challenge method out of the box, with HTTPS enforced on its protocol controllers, while its 2.3 default of reusable refresh tokens is a defaults gap, not a missing capability: rotation is a per-client config switch in 2.3, which 2.4 turns on by default. Duende turns on automatic signing-key management and data-protected grant storage by default. OpenIddict encrypts access tokens and rejects non-HTTPS protocol requests by default. Most of this can be corrected with additional configuration in each of the three products, so the list speaks to each vendor's defaults philosophy rather than to what you can ultimately achieve.
On track record, Abblix and OpenIddict have both published zero security advisories, but for Abblix, with a ~6.6K-download install base since 2024, that reflects limited external scrutiny at least as much as robustness. What bounds the unknown: protocol correctness is independently OIDF-certified across all seven OP profiles, and the vendor runs the same code in its own production identity provider; field-hardening at third-party scale remains unproven rather than disproven. Duende, with the longest commercial history of the three, has the most established security-response process.
Developer experience
Standing up the protocol layer costs little code in Abblix and Duende alike, since endpoints ship ready-made (Abblix's as MVC controllers, Duende's inside its own pipeline; Abblix's official sample host adds ~100 lines of wiring, UI aside), while OpenIddict requires the most protocol code by design, since you write the authorization and token endpoint logic yourself (the official all-flows sample's AuthorizationController runs ~700 lines, UI aside; a single-flow host is far smaller, but the endpoint logic is still yours to author). For the full user-facing surface the picture shifts: Duende's templates hand you a complete login/consent/logout/diagnostics page set to own, whereas neither Abblix nor OpenIddict ships production UI (Abblix's only login page is a demonstration in the Getting Started sample), so with either of the two, the whole user-facing surface, login included, is built from scratch.
The surrounding tooling widens that gap. Duende ships 7 templates (dotnet new, including EF and ASP.NET Identity variants) against Abblix's 2 and OpenIddict's 0, and roughly 36 client samples plus hosts and Aspire orchestration against OpenIddict's 16 official samples (web, desktop, OWIN) with 8 sandbox apps and Abblix's 4, the thinnest reference base. For admin and management UI, Duende has a first-party admin template plus a third-party ecosystem of commercial and open-source admin tools around it; OpenIddict has open-source community options; Abblix has none, first- or third-party.
Documentation follows the same shape: Duende's is the broadest (a multi-product site, numbered quickstarts, and per-version upgrade guides), OpenIddict's is solid but assumes you write endpoint code, and Abblix's is the smallest in narrative breadth (~20 hand-written pages and one deep getting-started tutorial, plus a generated API reference for Abblix.Oidc.Server and Abblix.Jwt) and English-only: the multilingual pages on abblix.com are the marketing site, not the docs. On release cadence and lifecycle, OpenIddict ships a breaking major roughly every 7-12 months with latest-stable-only support, Duende documents per-minor upgrades and maintains parallel patch lines, and Abblix has had one major break (2.0) with a committed migration guide and publishes per-major EOL dates after which a line is retired (1.x to Nov 2026, 2.x to Nov 2027), with patches delivered on the newest line.
Quality, testing, conformance
At shipped versions the test counts run ~2,700-2,850 methods for Duende 8.0.2, ~2,450 for Abblix 2.3, and ~1,700 for OpenIddict 7.5.0, context rather than a ranking, since the products' scopes differ. Only Duende has browser-driven E2E, and OpenIddict is the only one that runs its suite on .NET Framework. Abblix's own quality gaps: its tests execute on net10.0 only (the same source is multi-targeted, so what goes unverified is target-specific recompilation, not the logic), and CI runs on a single OS, bounded the same way: pure managed code over BCL crypto, with no OS-specific paths.
On certification (verified July 2026 against the OIDF OP-profiles and logout-profiles registries), Abblix is certified across seven OP profiles (including the Dynamic OP and 3rd-Party-Init profiles) plus four logout profiles, with shipped 2.3 inside the certified v2 line; Duende is certified across five OP profiles and all four logout profiles (v5/v6/v7, most recently 25 August 2024) and holds the only FAPI 2.0 certification of the three, with v8 (June 2026) not yet listed; and OpenIddict is deliberately uncertified, its README explaining that certifying a framework would not guarantee user deployments are compliant, shipping a conformance-ready sample instead. No product is certified for FAPI 1 Advanced; Abblix and OpenIddict hold no FAPI certification at all.
Ecosystem and community
The numbers are stark:
| Abblix | Duende | OpenIddict | |
|---|---|---|---|
| GitHub stars | 102 | 1,609 (products) | 5,184 |
| NuGet downloads (lifetime) | ~6.6K | ~25.4M | ~25.9-37.8M |
| StackOverflow questions | 0 | ~5,600 (incl. IdentityServer4 era) | 516 |
| Lifetime contributors | 2 | 311 | 70 |
| Releases, last 24 months | 14 | 23 (IdentityServer alone) | 15 stable |
| Third-party packages/UIs | none found | rich (commercial + open-source) | rich (open-source) |
Abblix is effectively a one-developer product (97% of all commits) from a small Kazakhstan-based vendor with a two-year public history and no third-party ecosystem. External pull requests are not accepted by policy (in-house development for architecture and license provenance), and external issue traffic is light so far, though bug reports and feature issues are welcome. It has shipped 14 releases in the last 24 months.
Duende has a multi-person team behind it and maintains parallel patch lines in practice: e.g. 7.3.x kept receiving patches after 7.4.0 shipped.
OpenIddict has the largest community and the only genuinely open contribution model: a sponsorship-funded project maintained primarily by one person, with roughly a decade of history and 70 lifetime contributors. Abblix and OpenIddict both patch only their newest release line.
Client-side and companion libraries
This is Abblix's largest gap. OpenIddict ships a complete free client stack in the same repo: an interactive web sign-in handler, desktop and mobile OS integration (Windows, macOS, Linux, iOS, and Android system browsers), a gallery of 111 preconfigured social and enterprise providers, and a validation stack for resource servers (local JWT or introspection, with database-backed revocation checks). Duende ships a certified native-app client (Duende.IdentityModel.OidcClient), automatic access-token management with DPoP support, and an introspection handler (all Apache 2.0), plus a separately licensed BFF framework (session management, anti-forgery, a YARP token-attaching proxy, Blazor support) and DPoP extensions for JwtBearer. Abblix ships no client-side code at all: its own samples use Microsoft's OpenIdConnect and JwtBearer handlers, and its BFF story is a single hand-rolled sample without token refresh, CSRF protection, or session management; a client package family is planned but unreleased.
For pure OP scenarios any standards-compliant client works against any of the three; if you want one vendor covering both sides of the wire, that is Duende's and OpenIddict's ground today.
Summary
Abblix OIDC Server
Where Abblix leads: it packs a broad modern-protocol surface into one package (CIBA with poll, ping, and push, DPoP, full DCR per RFC 7591 and 7592, JARM, RAR, token exchange, the JWT-bearer grant, JWT introspection responses, pairwise identifiers, per-client JWE, signed discovery metadata), and it is OpenID-certified across all seven OP profiles and all four logout profiles, current through the shipped 2.x line. Every capability is in every tier, the free one included, and license validation is offline, its enforcement code fully readable, and it contacts no remote server.
What you give up starts with operations. There are no first-party database stores, so durable persistence is the host's to wire behind the storage interfaces. Operational state runs on any distributed cache the host configures, and the client store is a plain read/write pair (IClientInfoProvider/IClientInfoManager) you can back with any database, relational or document, independent of that cache. Abblix's own IdP does exactly this in about a hundred lines of adapter code; the schema, migrations, and indexing are yours to design, and a relational client store is queryable. The real engineering is a queryable inventory of active grants and refresh tokens: they are stateless JWTs, so nothing on the server enumerates them, and that inventory is a stateful store you design and build yourself. There is no timer-based signing-key rotation, where Duende has it on by default (Abblix does overlapping manual rotation through a replaceable provider). And there is no admin UI, no first-party ASP.NET Identity package (a documented integration guide with a runnable sample exists), no client-side library, no BFF framework, no token-management helper: the entire user-facing UI, login included, is built from scratch.
The ecosystem is young and tiny now: ~6.6K downloads, no third-party packages. The free tier excludes commercial production use entirely. The docs (~20 pages, English-only) and sample base are the smallest, there is no FAPI certification where Duende has one, shipped 2.3 defaults to reusable refresh tokens (rotation is a per-client switch that 2.4 turns on by default), and only the newest release line receives patches (as with OpenIddict; Duende alone maintains parallel lines).
Duende IdentityServer
Where Duende leads: over a decade of lineage, 25M+ downloads, a multi-person team, and parallel patch lines. Its operational story is the strongest of the three: automatic key management on by default, EF Core stores, server-side sessions with a query/revocation API, an ASP.NET Identity package, built-in OpenTelemetry, an admin template plus a third-party ecosystem of commercial and open-source admin tools, 7 project templates, and 36+ samples.
Its documentation is the best of the three too: per-version upgrade guides and an official IdentityServer4 migration path. It ships a SAML IdP in the same engine (v8). And it holds the only FAPI certification of the three, FAPI 2.0 SP (Final) for v7.3, plus productized FAPI self-assessment tooling.
OpenIddict
Where OpenIddict leads: it is genuinely free and open source (Apache 2.0) at any scale, forkable, with the largest community of the three (5,184 stars, 70 contributors) and the only open contribution model. Its platform support is the widest (.NET Framework 4.6.2+/OWIN through .NET 10), and it is the only option for legacy ASP.NET hosts.
Its refresh-token reuse response is the strongest (replaying a redeemed token revokes the entire chain), and every issued token is tracked in its database-backed stores, revocable wherever token validation consults the store. It ships the richest free companion stack: a full web/desktop/mobile client, a 111-provider gallery, a validation/resource-server stack, and EF Core/EF6/MongoDB stores. And its engineering is the most transparent: 3-OS public CI, provenance attestations, trusted publishing, and a suite that runs on .NET Framework too.
When to choose which
Choose Abblix OIDC Server when you need a broad set of modern OAuth/OIDC protocol extensions in one package (the Summary above lists them), with every feature available in every tier including the free one, and you are comfortable being an early adopter of a young product from a small vendor: you design your own persistence against the library's storage interfaces (full control of the schema, but no ready-made stores), and you bring your own admin tooling, UI, and client-side stack.
Choose Duende IdentityServer when operational tooling and ecosystem matter most: over a decade of lineage, 25M+ downloads, automatic signing-key rotation, EF Core stores, server-side session management, ASP.NET Identity integration, built-in telemetry, an admin-UI ecosystem, the best documentation and migration guides, and you don't need the protocol extensions that set Abblix apart (JARM, RAR, first-party token exchange, ping/push CIBA), or when open-banking or another regulated program makes FAPI certification a gating requirement: Duende holds that certification today, Abblix does not.
Choose OpenIddict when budget or open source is a hard requirement, when you must run on .NET Framework/OWIN, or when you want the richest free client-side stack: it is a genuinely free, forkable framework with database-backed token storage and the strongest refresh-token reuse response. Its philosophy means more hand-written protocol code, and the protocol deltas against Abblix (DPoP, CIBA, server-driven logout notification) are shown in the protocol-coverage table above.
Whichever way the decision goes, all three are well-built products. This page is a map, not a verdict: the right answer depends on your project needs. Study all three before you decide.