Skip to content

Releases: Abblix/Oidc.Server

v1.0.100

03 May 19:44
v1.0.100
40b70ed
Compare
Choose a tag to compare

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