Skip to content

Abblix/Oidc.Server

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

470 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Abblix OIDC Server .NET language OS CPU security rating reliability rating maintainability rating CodeQL analysis tests NuGet Downloads GitHub release GitHub release date GitHub last commit getting started License Free

⭐ Star us on GitHub β€” your support motivates us a lot! πŸ™πŸ˜Š

Share Share Share Share Share

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.

Table of Contents

πŸš€ 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 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.

⚑ 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;
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.

✨ What's New

Version 2.3 (Latest)

πŸš€ 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.

⚠️ 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 β€” 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 Β§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 (AllowedSchemes, BlockPrivateNetworks) for trusted internal deployments.

πŸŽ“ Certification

OpenID Foundation Certification

We are certified in all profiles. During the certification process, we skipped ZERO tests and received NO warnings. All 634 tests Passed. 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:

Regular Profiles

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

Logout Profiles

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

πŸ“¦ 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 β€” 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.

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.

πŸ’Ž 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

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!

πŸ“ƒ License

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.

πŸ—¨οΈ Contacts

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:

Subscribe to our LinkedIn and Twitter:

LinkedIn X

We look forward to assisting you and ensuring your experience with our products is successful and enjoyable!

Back to top

Packages

 
 
 

Contributors

Languages