β 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, not a separate server to run and operate.
π For the full picture, see the technical overview.
- About
- Quickstart
- What's New
- Certification
- How to Install
- How to Build
- Documentation
- Feedback and Contributions
- License
- Contacts
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 to the letter β every OpenID profile, 634 conformance tests passed, zero skipped and zero warnings.
- 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 8, 9, and 10, 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.
Install the adapter for your hosting model and register the server in Program.cs:
dotnet add package Abblix.OIDC.Server.MVCusing Abblix.Jwt;
using Abblix.Oidc.Server.Mvc;
using Microsoft.IdentityModel.Tokens;
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(JsonWebKeyUseNames.Sig) };
});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.
π 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 Β§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.
Most deployments need only the first two; the rest apply if you use the named feature.
- Authorization response formatting unified.
IAuthorizationErrorFormatteris removed β success and error responses now flow through a singleIAuthorizationResponseFormatter, andAuthorizationErroris a subtype of the response model. Re-point any decorator or implementation toIAuthorizationResponseFormatterand branch onresponse 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 Β§3). Issue and require Initial Access Tokens, or set
OidcOptions.RequireInitialAccessToken = falseto keep open registration. - Back-channel logout endpoint validated at registration. A
backchannel_logout_uriwith a non-httpsscheme, internal hostname, or private/loopback address is rejected withinvalid_client_metadataunder the secure default. Register publichttpsendpoints, or relaxSecureHttpFetchOptions(AllowedSchemes,BlockPrivateNetworks) for trusted internal deployments.
We are certified in all profiles. During the certification process, we skipped ZERO tests and received NO warnings. All 634 tests . We are extremely proud of this achievement. It reflects our overall approach to any endeavor. 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:
| OIDC Profile | Response Types (links to official OpenID Foundation test results) | Tests |
|---|---|---|
| Basic OP | code | 36 |
| Implicit OP | id_token | 58 |
| Hybrid OP | code id_token | 102 |
| Config OP | config | 1 |
| Dynamic OP | code | code id_token | code id_token token | code token | id_token | id_token token | 127 |
| Form Post OP | basic | implicit | hybrid | 196 |
| 3rd Party-Init OP | code | code id_token | code id_token token | code token | id_token | id_token token | 12 |
| Total | 532 |
| OIDC Profile | Response Types (links to official OpenID Foundation test results) | Tests |
|---|---|---|
| RP-Initiated OP | code | code id_token | code id_token token | code token | id_token | id_token token | 66 |
| Session OP | code | code id_token | code id_token token | code token | id_token | id_token token | 12 |
| Front-Channel OP | code | code id_token | code id_token token | code token | id_token | id_token token | 12 |
| Back-Channel OP | code | code id_token | code id_token token | code token | id_token | id_token token | 12 |
| Total | 102 |
Add the adapter that matches your ASP.NET Core hosting model from NuGet.
For MVC controllers and routing:
dotnet add package Abblix.OIDC.Server.MVCFor Minimal API endpoint routing:
dotnet add package Abblix.OIDC.Server.MinimalApiBoth adapters expose the same OpenID Connect endpoints and pull in the core Abblix.OIDC.Server package as a dependency β pick the one that matches how your application maps requests. For hosts that wire the protocol layer directly, install Abblix.OIDC.Server instead.
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
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.
To better understand the Abblix OIDC Server product, we recommend visiting our Documentation site. There, you will find useful information about the product and the OpenID Connect standard.
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.
We've made every effort to implement all the main aspects of the OpenID protocol in the best possible way. However, the development journey doesn't end here, and your input is crucial for our continuous improvement.
Important
Whether you have feedback on features, have encountered any bugs, or have suggestions for enhancements, we're eager to hear from you. Your insights help us make the Abblix OIDC Server library more robust and user-friendly.
Please feel free to contribute by submitting an issue or joining the discussions. Each contribution helps us grow and improve.
For how we handle contributions β and why the library is developed in-house β see our Contributing Guidelines.
We appreciate your support and look forward to making our product even better with your help!
This product is distributed under a source-available proprietary license. See πLicense Agreement for details.
For non-commercial use, this product is available for free.
For more details about our products, services, or any general information regarding the Abblix OIDC Server, feel free to reach out to us. We are here to provide support and answer any questions you may have. Below are the best ways to contact our team:
- Email: Send us your inquiries or support requests at support@abblix.com.
- Website: Visit the official Abblix OIDC Server page for more information: Abblix OIDC Server.
Subscribe to our LinkedIn and Twitter:
We look forward to assisting you and ensuring your experience with our products is successful and enjoyable!
