Top.Mail.Ru
Cookies managing
We use cookies to provide the best site experience.
Cookies managing
Cookie Settings
Cookies necessary for the correct operation of the site are always enabled.
Other cookies are configurable.
Essential cookies
Always On. These cookies are essential so that you can use the website and use its functions. They cannot be turned off. They're set in response to requests made by you, such as setting your privacy preferences, logging in or filling in forms.
Analytics cookies
Disabled
These cookies collect information to help us understand how our Websites are being used or how effective our marketing campaigns are, or to help us customise our Websites for you.
Advertising cookies
Disabled
These cookies provide advertising companies with information about your online activity to help them deliver more relevant online advertising to you or to limit how many times you see an ad. This information may be shared with other advertising companies.

Abblix OIDC Server

Reliable authentication for your business
Abblix OIDC Server
Reliable authentication for your business
Abblix OIDC Server
Reliable authentication for your business
Are you planning to implement a modern authentication system?
Do you need a reliable and secure single sign-on (SSO) system?
Are you planning to create your own identity provider?

We know how to solve this task and will help you with it!

Why is the OpenID Connect protocol the best solution for authentication?

Unlike outdated and insecure protocols like OAuth 1.0, SAML, and WS-Federation, OpenID Connect is the most advanced and popular authentication standard, supported by numerous libraries and tools. It is the de facto standard in 2024.
It allows for easy addition of new domains and adaptation to changes in architecture without significant time and resource costs. This ensures scalability and long-term sustainability of solutions.
Easily integrates with existing systems, allowing for a seamless implementation of OpenID Connect into your infrastructure.
Compatibility
Provides reliable data protection and prevents unauthorized access. It separates user authentication processes from resource management, enhancing overall system security.
Security and
separation of
concerns
Provides a universal authentication mechanism for various platforms, such as web applications, mobile apps, smart TV apps, and more.
Mobile and
web applications
Modern standard
and broad support
Flexibility

Why is a Server Library better than a cloud or on-premise solution?

You decide where and how your data is stored. You control the storage format, backup, and data placement, including the choice of data centers and regions. Full control over user data helps ensure security and privacy. It also simplifies compliance with local and international regulations, such as GDPR and HIPAA, since the data remains within your infrastructure.
Data control and legal compliance
You can integrate the server library into your existing architecture, retaining your user database, authentication forms (UI), and current connections with other systems. The library allows for complete customization to meet your requirements, including any authentication factors: one-time passwords (OTP), biometrics, hardware keys, and their combinations. If you already have an account database, UI, or authentication service without OpenID Connect support, our solution will easily enable its integration.
Integration and
customization flexibility
Relying on cloud solutions can lead to challenges, when there is a need to move data to another provider or to your own data center. Data export can be difficult or impossible, risking data loss. By using your own solution with the OpenID Connect library, you avoid these risks. You maintain full control over your user base, independent of third-party providers and their policy changes, ensuring smooth transitions if you switch providers.
No vendor
lock-in
The conflict between the US and China has led to restrictions on cloud services and support. Brexit introduced additional requirements for data exchange between the UK and the EU. Some services were disrupted due to sanctions and new laws. By relying on your own authentication service, you eliminate the risks of cloud solution unavailability or lack of technical support. User authentication remains fully under your control.
No geopolitical
risks

  • Data control and legal compliance

    You decide where and how your data is stored. You control the storage format, backup, and data placement, including the choice of data centers and regions. Full control over user data helps ensure security and privacy. It also simplifies compliance with local and international regulations, such as GDPR and HIPAA, since the data remains within your infrastructure.
  • No vendor lock-in

    Relying on cloud solutions can lead to challenges, when there is a need to move data to another provider or to your own data center. Data export can be difficult or impossible, risking data loss. By using your own solution with the OpenID Connect library, you avoid these risks. You maintain full control over your user base, independent of third-party providers and their policy changes, ensuring smooth transitions if you switch providers.
  • Integration and customization flexibility

    You can integrate the server library into your existing architecture, retaining your user database, authentication forms (UI), and current connections with other systems. The library allows for complete customization to meet your requirements, including any authentication factors: one-time passwords (OTP), biometrics, hardware keys, and their combinations. If you already have an account database, UI, or authentication service without OpenID Connect support, our solution will easily enable its integration.
  • No geopolitical risks

    The conflict between the US and China has led to restrictions on cloud services and support. Brexit introduced additional requirements for data exchange between the UK and the EU. Some services were disrupted due to sanctions and new laws. By relying on your own authentication service, you eliminate the risks of cloud solution unavailability or lack of technical support. User authentication remains fully under your control.

Why choose OIDC Server?

There are many ways to implement a service that supports the OpenID Connect protocol. So why choose Abblix OIDC Server?

  • Easy integration and flexible architecture

    The library is ready to use with ASP.NET Core: standard controllers, data binding, and routing are all available out of the box. However, thanks to its hexagonal architecture, you can easily adapt and integrate the abstract core of the library into any existing or future frameworks for creating a Web API implementing the OpenID Connect protocol.
  • Modular design and open source

    The library is initially designed with a focus on ease of extension. We have separated the stages of validation, request processing, and response formatting, and supported library configuration through the standard .NET dependency injection mechanism. By applying well-known design patterns, you can easily add or modify virtually any aspect of the library's behavior to meet various project requirements. The source code is available on GitHub, ensuring development transparency and third-party security audits.
  • Cross-platform and .Net support

    The code is developed for the popular .NET platform, ensuring high compatibility and performance. The library runs on Windows and Linux servers, is compatible with Docker and Kubernetes, which simplifies deployment and scaling management.

  • Certification* and security

    The OIDC Server library is certified by the OpenID Foundation for all profiles. This ensures full compliance with standards for reliable and secure authentication.
OpenID Certified
*Abblix OIDC Server is certified by the OpenID Foundation.

Our library is 100% compliant with standards.
We passed certification tests flawlessly, without a single remark or warning.
Learn more by following these links:

OIDC Server in your infrastructure

User
database (DB)
Storing user information
Key Storage
Managing cryptographic keys
Logging and monitoring
Tracking and
recording events
Frontend (UI)
Rendering authentication forms
API and services
Integration with external and internal systems
Any deployment options
  • Physical server
  • Virtual server (e.g., VMWare, Hyper-V)
  • Docker container (with Kubernetes for orchestration)
  • User database (DB)
    Storing user information
  • Key Storage
    Managing cryptographic keys
  • Logging and monitoring
    Tracking and recording events
  • Frontend (UI)
    Rendering authentication forms
  • API and services
    Integration with external and internal systems
  • Any deployment options
    • Physical server
    • Virtual server (e.g., VMWare, Hyper-V)
    • Docker container (with Kubernetes for orchestration)
Abblix's responsibility:
Strict compliance with the OpenID Connect standard.
We take this on, providing you with the perfect solution.

Everything else is your responsibility.
We offer exceptional flexibility both when implementing the system from scratch and when upgrading an existing one. In the case of an upgrade, you can maximize the reuse of existing functionality, including authentication UI forms, key storage systems, logging, and user information databases.
Abblix's responsibility:
Strict compliance with the OpenID Connect standard.
We take this on, providing you with the perfect solution.

Everything else is your responsibility.
We offer exceptional flexibility both when implementing the system from scratch and when upgrading an existing one. In the case of an upgrade, you can maximize the reuse of existing functionality, including authentication UI forms, key storage systems, logging, and user information databases.

Technical requirements and implemented standards

  • Hardware requirements

    No specific hardware requirements are needed. System performance and memory capacity should effectively scale according to the operational loads of the system.
  • Web server requirements

    Any compatible web server, including:
    • Nginx
    • Apache HTTP Server
    • Microsoft IIS
  • Supported platforms

    • Runs on .NET-compatible platforms.
    • Supports .NET 8.0, .NET 9.0 and .NET 10.0.
  • Hardware requirements

    No specific hardware requirements are needed. System performance and memory capacity should effectively scale according to the operational loads of the system.
  • Web server requirements

    Any compatible web server, including:
    • Nginx
    • Apache HTTP Server
    • Microsoft IIS
  • Supported platforms

    • Runs on .NET-compatible platforms.
    • Supports .NET 8.0, .NET 9.0 and .NET 10.0.
The OAuth 2.0 Authorization Framework: RFC 6749: Defines procedures for secure authorization of applications including authorization code, implicit, client credentials, and resource owner password credentials flows.
The OAuth 2.0 Authorization Framework: Bearer Token Usage: RFC 6750: Explains how to securely use bearer tokens to access resources.
OAuth 2.0 Token Revocation: RFC 7009: Describes methods to securely cancel access and refresh tokens.
OAuth 2.0 Token Introspection: RFC 7662: Allows resource servers to verify the active state and metadata of tokens.
Proof Key for Code Exchange (PKCE): RFC 7636: Improves security for public clients during authorization code exchange with S256 and plain methods.
OAuth 2.0 Device Authorization Grant: RFC 8628: Enables OAuth 2.0 authorization on devices with limited input capabilities (smart TVs, game consoles, IoT devices) by delegating user interaction to a secondary device. Includes brute force protection with exponential backoff and per-IP rate limiting (RFC 8628 Section 5.2), plus atomic device code redemption to prevent race conditions (RFC 8628 Section 3.5).
OAuth 2.0 Dynamic Client Registration Protocol: RFC 7591: Provides mechanisms for clients to register dynamically with authorization servers.
OAuth 2.0 Dynamic Client Registration Management Protocol: RFC 7592: Enables management operations (read, update, delete) for dynamically registered clients.
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens: RFC 8705: Provides mutual TLS authentication with PKI and self-signed certificate validation, plus certificate-bound tokens.
OAuth 2.0 Token Exchange: RFC 8693: Details the method for a secure exchange of one token type for another.
OAuth 2.0 Resource Indicators: RFC 8707: Enables clients to specify the resources they want access to, enhancing security and access control.
JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens: RFC 9068: Specifies the use of JWTs as OAuth 2.0 access tokens.
JWT-Secured Authorization Request (JAR): RFC 9101: Secures authorization requests using JWTs.
OAuth 2.0 Pushed Authorization Requests (PAR): RFC 9126: Enhances security by allowing clients to push authorization requests directly to the server.
OAuth 2.0 Authorization Server Issuer Identification: RFC 9207: Ensures the authenticity of authorization servers to clients.
OAuth 2.0 Multiple Response Type Encoding Practices: Specification: Encodes different response types in OAuth 2.0 requests.
OAuth 2.0 Form Post Response Mode: Specification: Transmits OAuth 2.0 responses via HTTP form posts.
JWT Secured Authorization Response Mode (JARM): Specification: Secures authorization responses using JWTs.
JSON Web Signature (JWS): RFC 7515: Defines digital signature and MAC methods for JSON data structures.
JSON Web Encryption (JWE): RFC 7516: Defines encryption methods for JSON data structures.
JSON Web Key (JWK): RFC 7517: Defines a JSON representation of cryptographic keys.
JSON Web Algorithms (JWA): RFC 7518: Defines cryptographic algorithms for use with JWS, JWE, and JWK.
JSON Web Token (JWT): RFC 7519: Defines structure and use of JWTs for representing claims securely.
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants: RFC 7523: Uses JWTs for secure client authentication (private_key_jwt, client_secret_jwt) and as authorization grants.
OpenID Connect Core 1.0: Specification: Core functionality for OpenID Connect identity layer over OAuth 2.0, including ID Token issuance, standard claims, and authentication flows.
OpenID Connect Discovery 1.0: Specification: Enables clients to discover provider configurations dynamically via the well-known endpoint.
OpenID Connect Dynamic Client Registration 1.0: Specification: Enables OpenID Connect clients to register dynamically with providers.
OpenID Connect Session Management 1.0: Specification: Manages user session states in identity providers with check_session_iframe support.
OpenID Connect RP-Initiated Logout 1.0: Specification: Details logout initiated by relying parties via the end-session endpoint.
OpenID Connect Front-Channel Logout 1.0: Specification: Handles logout requests through front-channel communication.
OpenID Connect Back-Channel Logout 1.0: Specification: Manages logout processes using back-channel communication with logout tokens.
OpenID Connect Client-Initiated Backchannel Authentication (CIBA): Specification: Enables secure user authentication via backchannel communication on devices without direct web access, ideal for IoT and financial services scenarios. Supports three delivery modes: poll (client polls token endpoint), ping (server notifies client at callback), push (server delivers tokens to notification endpoint)
Pairwise Pseudonymous Identifiers (PPID): OpenID Connect Core Section 8: Implements a privacy mechanism by generating unique subject identifiers per client.
The OAuth 2.0 Authorization Framework: RFC 6749: Defines procedures for secure authorization of applications including authorization code, implicit, client credentials, and resource owner password credentials flows.
The OAuth 2.0 Authorization Framework: Bearer Token Usage: RFC 6750: Explains how to securely use bearer tokens to access resources.
OAuth 2.0 Token Revocation: RFC 7009: Describes methods to securely cancel access and refresh tokens.
OAuth 2.0 Token Introspection: RFC 7662: Allows resource servers to verify the active state and metadata of tokens.
Proof Key for Code Exchange (PKCE): RFC 7636: Improves security for public clients during authorization code exchange with S256 and plain methods.
OAuth 2.0 Device Authorization Grant: RFC 8628: Enables OAuth 2.0 authorization on devices with limited input capabilities (smart TVs, game consoles, IoT devices) by delegating user interaction to a secondary device. Includes brute force protection with exponential backoff and per-IP rate limiting (RFC 8628 Section 5.2), plus atomic device code redemption to prevent race conditions (RFC 8628 Section 3.5).
OAuth 2.0 Dynamic Client Registration Protocol: RFC 7591: Provides mechanisms for clients to register dynamically with authorization servers.
OAuth 2.0 Dynamic Client Registration Management Protocol: RFC 7592: Enables management operations (read, update, delete) for dynamically registered clients.
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens: RFC 8705: Provides mutual TLS authentication with PKI and self-signed certificate validation, plus certificate-bound tokens.
OAuth 2.0 Token Exchange: RFC 8693: Details the method for a secure exchange of one token type for another.
OAuth 2.0 Resource Indicators: RFC 8707: Enables clients to specify the resources they want access to, enhancing security and access control.
JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens: RFC 9068: Specifies the use of JWTs as OAuth 2.0 access tokens.
JWT-Secured Authorization Request (JAR): RFC 9101: Secures authorization requests using JWTs.
OAuth 2.0 Pushed Authorization Requests (PAR): RFC 9126: Enhances security by allowing clients to push authorization requests directly to the server.
OAuth 2.0 Authorization Server Issuer Identification: RFC 9207: Ensures the authenticity of authorization servers to clients.
OAuth 2.0 Multiple Response Type Encoding Practices: Specification: Encodes different response types in OAuth 2.0 requests.
OAuth 2.0 Form Post Response Mode: Specification: Transmits OAuth 2.0 responses via HTTP form posts.
JWT Secured Authorization Response Mode (JARM): Specification: Secures authorization responses using JWTs.
JSON Web Signature (JWS): RFC 7515: Defines digital signature and MAC methods for JSON data structures.
JSON Web Encryption (JWE): RFC 7516: Defines encryption methods for JSON data structures.
JSON Web Key (JWK): RFC 7517: Defines a JSON representation of cryptographic keys.
JSON Web Algorithms (JWA): RFC 7518: Defines cryptographic algorithms for use with JWS, JWE, and JWK.
JSON Web Token (JWT): RFC 7519: Defines structure and use of JWTs for representing claims securely.
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants: RFC 7523: Uses JWTs for secure client authentication (private_key_jwt, client_secret_jwt) and as authorization grants.
OpenID Connect Core 1.0: Specification: Core functionality for OpenID Connect identity layer over OAuth 2.0, including ID Token issuance, standard claims, and authentication flows.
OpenID Connect Discovery 1.0: Specification: Enables clients to discover provider configurations dynamically via the well-known endpoint.
OpenID Connect Dynamic Client Registration 1.0: Specification: Enables OpenID Connect clients to register dynamically with providers.
OpenID Connect Session Management 1.0: Specification: Manages user session states in identity providers with check_session_iframe support.
OpenID Connect RP-Initiated Logout 1.0: Specification: Details logout initiated by relying parties via the end-session endpoint.
OpenID Connect Front-Channel Logout 1.0: Specification: Handles logout requests through front-channel communication.
OpenID Connect Back-Channel Logout 1.0: Specification: Manages logout processes using back-channel communication with logout tokens.
OpenID Connect Client-Initiated Backchannel Authentication (CIBA): Specification: Enables secure user authentication via backchannel communication on devices without direct web access, ideal for IoT and financial services scenarios. Supports three delivery modes: poll (client polls token endpoint), ping (server notifies client at callback), push (server delivers tokens to notification endpoint)
Pairwise Pseudonymous Identifiers (PPID): OpenID Connect Core Section 8: Implements a privacy mechanism by generating unique subject identifiers per client.

Want to test the product?

Not sure if it will integrate with your system?
Have questions about the library's capabilities or pricing plans?

Fill out the form, and we'll do our best to address your questions!
By clicking the button, you consent to the processing of your personal data and confirm that you have read the Privacy Policy.