Create an OIDC Connector

The OpenID Connect (OIDC) connector allows SigningHub to connect with any third-party authentication service that supports OIDC protocol such as Google and Azure Active Directory. This is a generic configuration so the "Auth URL" provided in the connector will be used for identifying the third-party service configured to authenticate the user both at the time of login and at the time of signing.

Create an OIDC connector:

Click the "Configurations" option from the left menu.
Choose the "Connectors" option.
The "Connectors" screen will appear.
Click the add icon from the grid header.

A dialog will appear to add the connector details. The connector dialog is comprised of two sections, i.e. Basic Information and Details.
The following table describes the fields on the "Basic Information" section of this dialog.

Basic Information Section
Fields	Description
Name	Specify a unique name for this connector, i.e. My Google. This connector will be used in the configuration of Authentication Profiles.
Provider	Select the provider for this connector, i.e. "OIDC".
Purpose	This field will display the purpose of the selected provider above, i.e. the purpose of "OIDC" is "Authentication".
Active	Select to make this connector active. Keep the check box empty to make the connector In-active. An inactive connector cannot be configured in the Authentication Profiles.
Next	Displays the "Details" section.

The following table describes the fields on the "Details" section of this dialog.

Details Section
Fields	Description
Logo	Select an appropriate image in the jpeg, jpg, gif or png format for the connector's logo that will be displayed on the login screen.
Discover Document URL	Specify the "Discovery Document URL", OpenID Connect defines a discovery mechanism, called OpenID Connect Discovery, where an OpenID server publishes its metadata at a well-known URL, typically https://server.com/.well-known/openid-configuration This URL returns a JSON listing of the OpenID/OAuth endpoints like [Auth URL] that is third-party authentication server URL. For example, "https://accounts.google.com/o/oauth2/v2/auth" is for Google and [Access Token URL] that is third-party authentication server URL for exchanging the authorization code for an access token. For example, "https://www.oauth2.googleapis.com/token" is provided by Google. , supported scopes and claims, public keys used to sign the tokens, and other details.
Client ID	Specify the registered client ID as provided by the third-party authentication server. By default, the text is masked with asterisks, you can click to view the entered text.
Client Secret	Specify the client secret as provided by the third-party authentication server. By default, the text is masked with asterisks, you can click to view the entered text.
Scope	REQUIRED OpenID Connect requests MUST contain the openid scope value. (its auto filled in field) add more parameters if needed like National ID, email, or profile (separated with empty space) OpenID Connect Clients use scope values to specify what access privileges are being requested for Access Tokens.
Callback URL	URL that OAuth invokes after the authentication process completed.OAuth redirects back to this URL and appends additional parameters to it, including an access code which will be exchanged for an id_token, access_token and refresh_token. For example if your SigningHub site is "https://web.signinghub.com" then the Callback URL will be "https://web.signinghub.com/OIDC/CallBack".
PKCE	When checked, the Proof Key for Code Exchange (PKCE) mechanism will be enabled, adding an extra security layer for public clients. It will require a code challenge and verifier during the OAuth flow to prevent interception of authorization codes.
State	When checked, the system will automatically include a random string with each authentication request. This will protect against Cross-Site Request Forgery (CSRF) attacks by validating the integrity of the request once it returns from the identity provider.
Nonce	When checked, a unique nonce will be added to the authentication request to prevent token replay attacks. It ensures that the token can only be used for the specific request it was generated for.
Language	When checked, the system will determine the appropriate language for the login screen based on either the user's locale settings or the system's default settings. This will allow the login screen to be displayed in the user's preferred language.
Display	This dropdown appears when the checkbox is checked. It allows you to choose how the login screen should be displayed: page: The login screen will be displayed as a full-page view. popup: The login screen will be shown in a popup window. touch: Optimized view for mobile devices. wap: A simplified version for older mobile browsers.
Prompt	This dropdown appears when the checkbox is checked. It allows you to define how the user will be prompted during authentication: none: No prompt is displayed; if the user is already logged in, they will be authenticated automatically. login: Forces the user to log in again. consent: Forces the user to give consent for sharing information. select_account: Prompts the user to select from multiple accounts.
Max Age	When checked, an additional input field appears allowing you to specify the maximum allowable time (in seconds) since the user's last authentication. If the user was authenticated earlier than this time, they will be prompted to log in again.
Login Hint	When checked, an input field appears where you can specify a login hint (such as an email or username). This hint will be pre-filled on the login screen to assist the user in logging in.
ACR Values	When checked, a text box will appear where you can specify Authentication Context Class References (ACR) values. These values indicate the level of authentication (e.g., multi-factor authentication or other methods) required during the authentication process. This field allows you to define which authentication contexts the client must use.
Client Authentication	When checked, a dropdown menu appears with the following authentication methods to secure communication with the OpenID Connect provider: client_secret_basic: The client secret is sent via the HTTP Authorization header. client_secret_post: The client secret is included in the HTTP POST body. client_secret_jwt: The client secret is used to create a JSON Web Token (JWT) which is signed and sent. private_key_jwt: A JWT signed using a private key is sent for authentication. none: No client authentication is used, suitable for public clients that don't require credentials. These options let you choose the appropriate method based on the security requirements of the connection.
Client Auth Signing Certificate (PKCS#12):	This field appears when "private_key_jwt" is selected as the authentication method in "Client Authentication." Choose the PKCS#12 (PFX) file containing your private key. Ensure that the corresponding public certificate is trusted on the OIDC portal to secure communication between the client and the provider.
Client Auth Signing Certificate Password:	This field appears when "private_key_jwt" has been selected as the authentication method in the "Client Authentication" field. Provide the password to unlock your PFX file. This password grants access to the private key needed for client authentication with the OIDC provider.
Finish	Creates a new connector using the information entered on the dialog.

If "private_key_jwt" is selected as the authentication method, the request must include a public key (or a URL) that should be used to verify the signature as a JSON Web Key Set (JWKS).