v1.2.0.1

🛠 Fixes

• Fixed the Denial of Service vulnerability identified in System.Security.Cryptography.Cose, System.IO.Packaging, and Microsoft.Extensions.Caching.Memory (CVE-2024-43483) (PR#18)

Detailed description

Fixed Denial of Service vulnerability (CVE-2024-43483)

• A high-severity vulnerability in System.Security.Cryptography.Cose, System.IO.Packaging, and Microsoft.Extensions.Caching.Memory was identified. The issue made the system susceptible to hash flooding attacks through hostile input, potentially leading to a Denial of Service (DoS). This vulnerability affects multiple versions of .NET, specifically .NET 6.0, .NET 8.0, and .NET 9.0, and has now been patched.
  • Vulnerable versions: .NET 6.0 (<= 6.0.1), .NET 8.0 (<= 8.0.0), .NET 9.0 (<= 9.0.0-rc.1.24431.7)
  • Patched versions: .NET 6.0.2, .NET 8.0.1, .NET 9.0.0-rc.2.24473.5
  • Developers using affected versions are advised to update to the latest patched versions to mitigate the risk of Denial of Service attacks.

v1.2.0

🚀 Features

• Added support for Client-Initiated Backchannel Authentication (CIBA) with a dedicated backchannel authentication endpoint (PR#17)

Detailed description

Added support for CIBA with a dedicated backchannel authentication endpoint

• Added support for CIBA with a dedicated endpoint compliant with the Client-Initiated Backchannel Authentication (CIBA) standard. This allows clients to initiate authentication through a secure backchannel.
• Supports Signed Authentication Requests, allowing clients to send JWS-signed requests for enhanced security. This ensures that the requests are tamper-proof and that their integrity can be verified by the server.
• The token endpoint now supports Poll Mode for CIBA, enabling clients to poll for tokens during the backchannel authentication process. Poll Mode is one of the standard delivery modes defined in the CIBA specification, alongside ping and push modes.
• Full support for the CIBA grant type (urn:openid:params:grant-type:ciba) at the token endpoint, ensuring seamless token exchange once authentication is completed.
• Enhanced OpenID Provider Metadata includes the URL of the backchannel authentication endpoint, lists supported delivery modes (poll, ping, push), and specifies the supported JWS signing algorithms for authentication requests. These metadata elements are crucial for dynamic client registration and discovery, ensuring interoperable interactions between clients and providers.
• Client Metadata defines the token delivery mode (poll, ping, push), requires the client notification endpoint for ping and push modes, and specifies the request signing algorithm for authentication requests. This provides clients with the necessary configuration details to interact effectively with the OpenID Provider.

v1.1.0

🚀 Features

• Added Resource Indicators support (RFC 8707) (PR#12)

🛠️ Fixes

• Fixed issuer parameter return from Authorization endpoint (PR#11)
• Fixed some suggestions from SonarQube

Detailed description

Added Resource Indicators support

• RFC 8707 Resource Indicators for OAuth 2.0: Introduces a mechanism allowing OAuth 2.0 clients to specify the target resource they wish to access by including a resource parameter in the authorization request. This enables the authorization server to determine the appropriate policies and scopes required for accessing the specified resource. By providing explicit resource indicators, this feature enhances security and granularity in access control, ensuring that tokens are scoped to specific resources and reducing the risk of unauthorized resource access.
  • The system supports multiple resources, allowing clients to request access to multiple resources in a single authorization request. This enables more complex and comprehensive access scenarios.
  • Clients can define their own scopes with custom sets of claims, as well as their own resources with associated scope sets. This allows for more tailored and specific access controls suited to individual customer needs.
  • The consent process for users has been extended. Users can now provide partial consent, granting access to some of the requested scopes and resources while denying others. This improves user control and privacy by allowing more granular consent decisions.
  • Clients can request an access token for a subset of scopes and resources that were granted in a prior authorization request. This supports more efficient and focused access patterns, reducing the need to request full sets of scopes and resources repeatedly.

Fixed issuer parameter return from Authorization endpoint

• Corrected the implementation to ensure that the iss (issuer) parameter is accurately returned from the Authorization endpoint. The iss parameter identifies the authorization server issuing the token, and ensuring its correct return is crucial for validating tokens and maintaining trust in the authentication process. This fix ensures interoperability with clients and services relying on the issuer information for security and validation purposes.

Fixed some suggestions from SonarQube

• Implemented several recommendations and fixes based on analysis from SonarQube, a tool for continuous inspection of code quality. This includes addressing code smells, potential bugs, and security vulnerabilities identified by SonarQube. Improvements involve refactoring code for better readability and maintainability, fixing bugs that could lead to runtime errors, and enhancing security by addressing identified vulnerabilities. These changes contribute to a more robust, secure and maintainable codebase.

v1.0.100

🚀 Features

• OpenID Connect Core and Discovery support
• OAuth 2.0 Authorization framework and token handling
• Dynamic Client Registration
• Session Management
• Multiple logout methods
• Pairwise Pseudonymous Identifiers (PPID)
• Improved security for public clients (PKCE)
• Enhanced security for authorization requests (JAR, PAR)

Detailed description

OpenID Connect Core and Discovery support

• OpenID Connect Core: A standard identity layer built on top of OAuth 2.0, which provides a simple, standardized way for clients (applications) to verify the identity of an end-user based on the authentication performed by an Authorization Server (OpenID Provider). It also allows the client to securely obtain basic profile information about the user. This is done in an interoperable manner using RESTful APIs and provides standardized ways to ensure security and privacy.
• OpenID Connect Discovery: A standard that helps clients dynamically discover the necessary information about the OpenID Provider by fetching metadata from a standard URL. This simplifies client configuration, as the discovery document contains endpoints and configuration details required for the OpenID Connect flow, enabling seamless integration.

OAuth 2.0 Authorization framework and token handling

• OAuth 2.0: A widely used framework that enables third-party applications to gain limited access to a web service on behalf of a resource owner. This is achieved by orchestrating an approval interaction between the resource owner and the service. OAuth also allows apps to obtain access on their own by using the client credentials.
• Bearer Token Usage: In OAuth 2.0, a bearer token allows access to protected resources by presenting the token to the service. This method ensures that the server can verify the validity of the token before granting access, reducing the risk of unauthorized access.
• Token Introspection: A mechanism for validating the status of a token. It allows a server to query the authorization server to check if a token is valid or expired, including additional details like scopes and expiration time. This ensures secure and accurate token usage.
• Token Revocation: Allows clients or users to explicitly revoke tokens, making them invalid for further use. This is crucial for promptly terminating access when necessary, such as when an access token is compromised.

Dynamic Client Registration

• Dynamic Client Registration: Provides a way for clients to register dynamically with the OpenID Provider. This means that a client application can register itself with the provider, obtaining client credentials (client ID and client secret) without manual intervention. It simplifies client onboarding and configuration, especially for large-scale deployments where automation is crucial.

Session Management

• Session Management: Enables the monitoring of user authentication states across applications that rely on the same OpenID Provider. This ensures a consistent and secure user experience by handling scenarios like Single Logout, where logging out from one application triggers the logout process for all other associated applications. Additionally, it allows RPs (Relying Parties) to detect changes in the user's session, such as when the user logs in or out from another application, ensuring updated session information.

Multiple logout methods

• RP-Initiated Logout: Allows an application (Relying Party) to initiate the logout process. This ensures that not only is the user logged out from the specific application but also from the OpenID Provider, terminating the session for all other Relying Parties using the same OpenID Provider.
• Front-Channel Logout: Utilizes the user's web browser to send logout requests to the OpenID Provider. This method is particularly suitable for web applications where the browser is used to communicate the logout request directly.
• Back-Channel Logout: Communicates logout requests directly between the OpenID Provider's server and the Relying Party's server. This approach provides enhanced security by keeping the logout process behind the scenes, preventing potential interception or manipulation.

Pairwise Pseudonymous Identifiers (PPID)

• PPID: A privacy feature that ensures unique and persistent identifiers for each user, specific to the application. This means that each application receives a different identifier for the same user, preventing cross-application tracking and enhancing user privacy. The identifiers are designed to remain consistent for the same application over time but cannot be used to correlate user identities across different applications.

Improved security for public clients (PKCE)

• PKCE (Proof Key for Code Exchange): A security enhancement for OAuth 2.0 used mainly for public clients like mobile and desktop applications. It adds an extra layer of security by requiring the client to generate a code verifier and a code challenge. This prevents authorization code interception attacks by ensuring that the authorization code can only be exchanged by the party that initially requested it.

Enhanced security for authorization requests (JAR, PAR)

• JWT-Secured Authorization Requests (JAR): Allows the client to send authorization requests as signed and optionally encrypted JWTs (JSON Web Tokens). This provides better integrity and confidentiality for authorization requests, ensuring that they cannot be tampered with during transit.
• Pushed Authorization Requests (PAR): A method where clients directly push authorization request parameters to the authorization server in a secured and authenticated manner. This enhances security by reducing the risk of interception or manipulation during the authorization process, as parameters are sent directly to the authorization server rather than through the user's browser.