⭐ Star us on GitHub: your support motivates us a lot! 🙏😊

Add a certified OpenID Connect provider to your own ASP.NET Core app, one you embed and own end to end rather than a separate server to run and operate.

📑 For the full picture, see the technical overview.

Table of Contents

• About
• Quickstart
• What's New
• Certification
• How to Install
• How to Build
• Documentation
• Abblix Account
• Feedback and Contributions
• License
• Contacts

🚀 About

Abblix OIDC Server turns your ASP.NET Core application into a fully certified OpenID Connect provider. Rather than deploying and operating a separate identity server, you embed the protocol directly into your app, so your users, your data, and your UI stay inside your product.

• Certified: all seven OpenID Provider profiles and all four logout profiles, 634 conformance tests passed with none skipped and no warnings. FAPI is not among them.
• A library you own, not a server you run: the OpenID Connect endpoints live inside your app, so users, data, and UI never leave it.
• Current with the modern security stack: DPoP, PAR, JARM, RAR, token exchange, and certificate-bound tokens, alongside the OAuth 2.0 and OpenID Connect core.
• Engineering you can audit: 2000+ passing tests, top SonarCloud security, reliability, and maintainability ratings, and CodeQL scanning on every change.
• Modern .NET, minimal friction: targets .NET 11, with drop-in adapters for both MVC and Minimal API.

Under the hood, the library leans on modular and hexagonal architecture and the standard .NET DI container, which keeps it testable and easy to extend. It ships two ASP.NET Core integration adapters that expose the same OpenID Connect endpoints (one for MVC controllers and routing, one for Minimal API endpoint routing), so you adopt whichever hosting model your application already uses, without taking a dependency on the other.

⚡ Quickstart

Install the adapter for your hosting model and register the server in Program.cs:

dotnet add package Abblix.OIDC.Server.MVC

using Abblix.Jwt;
using Abblix.Oidc.Server.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();

// Turn your ASP.NET Core app into an OpenID Connect provider
builder.Services.AddOidcServices(options =>
{
    options.LoginUri = new Uri("/Auth/Login", UriKind.Relative);
    options.SigningKeys = new[] { JsonWebKeyFactory.CreateRsa(PublicKeyUsages.Signature) };
});

That registers the full set of certified OpenID Connect endpoints. Point LoginUri at your login page and plug in your user store. The Getting Started Guide walks through a complete, runnable solution.

✨ What's New

Version 2.4 (Latest)

🚀 Features

• Minimal API integration: every OIDC endpoint as ASP.NET Core route handlers via the new Abblix.OIDC.Server.MinimalAPI package, with full protocol parity with the MVC integration
• External signing keys: private keys held in HashiCorp Vault / OpenBao Transit (Abblix.JWT.Vault) or Azure Key Vault (Abblix.JWT.Azure) - the private halves never enter the process, the public halves publish to the JWKS endpoint
• Security events and Shared Signals: a new package family implementing Security Event Tokens (RFC 8417) with Subject Identifiers (RFC 9493), push and poll SET delivery (RFC 8935, RFC 8936), the OpenID Shared Signals Framework 1.0 in both transmitter and receiver roles, and the CAEP 1.0 and RISC 1.0 event dictionaries

Version 2.3

🚀 Features

• Rich Authorization Requests (RFC 9396): fine-grained, transaction-level authorization details across the authorization endpoint, PAR, the token endpoint, CIBA, and the device grant, carried end-to-end into the access token
• Token Exchange (RFC 8693): impersonation and delegation with multiple subject- and actor-token formats and a per-client allow-list of subject-token types
• DPoP sender-constrained tokens (RFC 9449): signature-based proof of possession for public clients that cannot use mTLS, binding access and refresh tokens to the client key
• Certificate-bound access tokens (RFC 8705 Section 3): resource-server verification that a presented token matches the client certificate on the TLS connection
• JARM: the authorization response returned as a signed, optionally encrypted JWT, protecting it against tampering, mix-up, and parameter injection
• JWT-secured token introspection (RFC 9701): signed, optionally encrypted introspection responses via content negotiation
• JWE-encrypted request objects (RFC 9101): confidential request parameters in the front channel and by reference
• Signed authorization server metadata (RFC 8414): opt-in, integrity-protected discovery document

🔒 Security hardening

• Secure-by-default: Implicit Flow is now opt-in, and Dynamic Client Registration requires an Initial Access Token (RFC 7591)
• JOSE critical-header handling (RFC 7515): well-formed critical parameters are rejected until a host registers a handler bound to each parameter name
• Token-class confusion defense via opt-in token-type pinning (RFC 8725)
• JWS verification key pinned to its declared algorithm (RFC 7517) and enforced HMAC key length (RFC 7518)
• Pairwise subject identifier (PPID) derivation reimplemented as HMAC-based and key-rotatable, replacing the prior string-concatenation scheme (configurable hash and salt)
• Authorization-response issuer parameter (RFC 9207) now advertised in discovery, so clients can require and verify the mix-up defense

✏️ Improvements

• Structured logging via a source generator across the whole server: named events with stable numeric identifiers, ready for audit pipelines
• Unified client-addressed JWT signing and encryption across UserInfo, identity-token, JARM, and introspection responses
• JWT validation returns errors instead of throwing on unsupported algorithm or key combinations
• Dependency-injection registrations normalized so host pre-registrations win the resolution race

See 📋Release Notes for full details of 2.4, and 2.3 for the release before it.

⚠️ Breaking Changes (upgrading from 2.2)

Most deployments need only the first two; the rest apply if you use the named feature.

• Authorization response formatting unified. IAuthorizationErrorFormatter is removed, and success and error responses now flow through a single IAuthorizationResponseFormatter, and AuthorizationError is a subtype of the response model. Re-point any decorator or implementation to IAuthorizationResponseFormatter and branch on response is AuthorizationError (the { RedirectUri: null } variant is the one to render on your own error page).
• Implicit Flow is opt-in. Implicit and hybrid response types are rejected at client registration unless you call EnableImplicitFlow() on the OIDC builder. Authorization Code Flow is the default; no action otherwise.
• Initial Access Token required for Dynamic Client Registration. Anonymous registration is rejected by default (RFC 7591 Section 3). Issue and require Initial Access Tokens, or set OidcOptions.RequireInitialAccessToken = false to keep open registration.
• Back-channel logout endpoint validated at registration. A backchannel_logout_uri with a non-https scheme, internal hostname, or private/loopback address is rejected with invalid_client_metadata under the secure default. Register public https endpoints, or relax SecureHttpFetchOptions for trusted internal deployments: set BlockPrivateNetworks to false and state AllowedSchemes in full, https included - the list replaces the default rather than extending it.

🎓 Certification

We are certified in all profiles. During the certification process, we skipped ZERO tests and received NO warnings. All 634 tests . For more details, click the links (Certified OpenID Providers & Profiles, Certified OpenID Providers for Logout Profiles).

For convenience, the certification information is provided in the tables below:

Regular Profiles

Logout Profiles

📦 How to Install

Add the adapter that matches your ASP.NET Core hosting model from NuGet.

For MVC controllers and routing:

dotnet add package Abblix.OIDC.Server.MVC

For Minimal API endpoint routing:

dotnet add package Abblix.OIDC.Server.MinimalApi

Both adapters expose the same OpenID Connect endpoints and pull in the core Abblix.OIDC.Server package as a dependency, so pick the one that matches how your application maps requests. For hosts that wire the protocol layer directly, install Abblix.OIDC.Server instead.

📝 How to Build

To build the packages, follow these steps:

# Open a terminal (Command Prompt or PowerShell for Windows, Terminal for macOS or Linux)

# Ensure Git is installed
# Visit https://git-scm.com to download and install console Git if not already installed

# Clone the repository
git clone https://github.com/Abblix/Oidc.Server.git

# Navigate to the project directory
cd Oidc.Server

# Check if .NET SDK is installed
dotnet --version  # Check the installed version of .NET SDK
# Visit the official Microsoft website to install or update it if necessary

# Restore dependencies
dotnet restore

# Compile the project
dotnet build

📚 Documentation

Getting Started

Explore the Getting Started Guide. In this guide, you will create a working solution step by step, building an OpenID Connect Provider using ASP.NET MVC and the Abblix OIDC Server solution.

The Documentation site covers configuration, deployment, the API reference and the OpenID Connect standard itself.

💎 Abblix Account

Prefer not to run the provider yourself? Abblix Account is a ready-to-use service hosted in the cloud, built on this library. You get passkeys, MFA, social login, and security event notifications: everything your users need, integrated into your website in minutes.

👉 See it live: Quorvel Coffee is a demo application using Abblix Account for user authentication. It shows how sign-in flows, session management, and user self-service, all delivered by Abblix Account, fit into a client website.

🤝 Feedback and Contributions

The protocol surface is complete and certified, but the library is not finished. What you run into in your own application is what we cannot see from here.

[!IMPORTANT] Whether you have feedback on features, have encountered any bugs, or have suggestions for enhancements, we're eager to hear from you. A report that names the flow and the client you were using is what turns a guess into a fix.

Please feel free to contribute by submitting an issue or joining the discussions.

For how we handle contributions, and why the library is developed in-house, see our Contributing Guidelines.

📃 License

This product is distributed under a source-available proprietary license. See 📋License Agreement for details.

It is free of charge for companies under $1M in annual revenue and under $1M raised in outside funding, for non-profits, educational institutions, personal projects and non-commercial open source, and for development, test and staging environments at any size. Every protocol is included at every tier, with no limit on client applications or users, and one production issuer per free deployment. See the pricing page.

🗨️ Contacts

For more details about our products, services, or any general information regarding the Abblix OIDC Server, feel free to reach out to us. Below are the best ways to contact our team:

• General inquiries: info@abblix.com
• Support and security reports: support@abblix.com, see the Security Policy
• Website: Visit the official Abblix OIDC Server page for more information: Abblix OIDC Server.

Subscribe to our LinkedIn and Twitter:

Back to top