Oidc.Server

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

🔥 Why OIDC Server is the best choice for authentication — find out in our presentation 📑

Abblix Account

💎 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.

Table of Contents

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

🚀 About

Abblix OIDC Server is a .NET library designed to provide comprehensive support for OAuth2 and OpenID Connect on the server side. It adheres to high standards of flexibility, reusability, and reliability, utilizing well-known software design patterns, including modular and hexagonal architectures. These patterns ensure the following benefits:

• Modularity: Different parts of the library can function independently, enhancing the library's modularity and allowing for easier maintenance and updates.
• Testability: Improved separation of concerns makes the code more testable.
• Maintainability: Clear structure and separation facilitate better management of the codebase.

The library also supports Dependency Injection through the standard .NET DI container, aiding in the organization and management of code. Specifically tailored for seamless integration with ASP.NET WebApi, Abblix OIDC Server employs standard controller classes, binding, and routing mechanisms, simplifying the integration of OpenID Connect into your services.

✨ 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

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:

Regular Profiles

Logout Profiles

📝 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.

🤝 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.

We appreciate your support and look forward to making our product even better with your help!

Pre-commit hooks (one-time setup per clone)

If you plan to send a pull request, set up local hooks once:

pip install pre-commit
pre-commit install

After this, git commit automatically runs actionlint and a custom secrets-interpolation check on any change to .github/workflows/. The same checks run in CI as a backstop, so the worst case is a 1–2 minute round-trip; pre-commit just makes it faster.

📃 License

This product is distributed under a 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:

• Email: Send us your inquiries or support requests at [email protected].
• 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!

Back to top