Skip to content
Contact us

Introduction to Abblix OIDC Server

Abblix OIDC Server is a .NET library that implements OAuth 2.0 and OpenID Connect on the server side. It was built by developers who had spent years working with IdentityServer4 in production and accumulated a long list of things they would have designed differently. We wrote up why that history led to a new library rather than another fork.

The result is a library built for ASP.NET Core from the ground up: not a port, not a wrapper, but an implementation that treats routing, middleware, model binding, and dependency injection as first-class primitives.

What makes it different

Certification across all profiles

Abblix OIDC Server is certified by the OpenID Foundation across all login and logout profiles (Basic, Implicit, Hybrid, Config, Dynamic, Form Post, 3rd Party-Init, and all logout variants) with zero failures and zero skipped tests in 600+ conformance checks. The results are public and independently verifiable at the OpenID Foundation site. This is the most objective measure of protocol correctness available, and it's the strongest argument we make.

Designed for extensibility

Authentication flows need layering: consent steps, custom claims, overridden token lifetimes, tenant-specific logic. Abblix OIDC Server is structured around small, composable interfaces using Composite and Decorator patterns throughout. Each extension point is sized to the behavior you're changing, not a thousand-plus-line class you need to understand before touching.

ASP.NET Core native

The library integrates with ASP.NET Core the way your own controllers do. Standard routing, standard filters, standard debugging: no parallel middleware world to learn. Teams already building on .NET don't hit a conceptual wall when they add Abblix OIDC Server.

Built on System.Text.Json.Nodes end to end

Claims are JsonNode values, not name/string pairs. Complex JWT payloads (arrays, nested objects, typed values) work without serialization workarounds.

Private keys outside the process

The signing and encryption keys can live in an HSM or a managed KMS: packages for HashiCorp Vault or OpenBao Transit and for Azure Key Vault ship with the library, and any other vault takes one implementation of IKeyCustodian, plus a store for the sealed keys if they are minted in the process. Held in the vault, a private key never enters the server process, and every signature is made there. Minted in the process instead, each key is sealed to a vault key and signing stays local: no vault call per token, at the cost of the opened key living in the server's memory. The choice is explicit: a server with a vault registered and no placement chosen does not start. Keys in an HSM or KMS compares the two placements.

What it covers

The library implements OAuth 2.0 and OpenID Connect flows, PKCE, token introspection and revocation, dynamic client registration, device authorization, mutual TLS, pushed authorization requests, JWT-secured authorization requests, CIBA, and the full OpenID Connect suite including session management, front-channel and back-channel logout, and dynamic provider discovery. See Implemented Standards for the complete list with RFC references.

What it doesn't do (yet)

Entity Framework Core and ASP.NET Identity stores are on the roadmap for Q4 2026. Until then, you implement the persistence interfaces yourself: typically 200-400 lines wired to whatever database you already use. If you actually need ready-made EF Core stores, that's the one thing to keep in mind.

Where to go next

Next
Navigating Identity Management