AuthID Integration

Overview

Configuring authID's backend and user-preferred identity provider are the two separate locations that must be configured to establish a connection to the authID OIDC service. Along with examples of well-known identity providers users can integrate with, this page walks through creating an integration within authID.

Identity Portal

Although some users prefer to use the API endpoints to generate an OIDC integration within authID's backend system, this guide covers the integration creation via the Identity Portal.

Start login to the Identity Portal and navigate to the Cloud Connections > OpenID > New Connection blade of the menu:

New Connection

Access Policy

This page contains various scenarios where a user encounters the desired behavior of the OIDC connection.

📘

Biometric or Virtual Passkey must allow the user to:

• If enrolled, authenticate using a biometric.
• If enrolled, authenticate using a virtual passkey.
• Always utilize biometric authentication if the user has enrolled both credentials.
• Invoke the configured enrollment policy if the user is unable to utilize either their biometric or virtual passkey.

1. Authentication: During sign-in users must perform primary authentication. Based on the selected primary authentication type, the below authentication fields are enabled.
   • During Passkey authentication, users are shown the following transaction template.
   • When verifying a user biometric, verification is always performed via.
   • During biometric verification, users are shown the following transaction template.

2. Enrollment: Based on the enrollment type, the below-enrolling scenarios are enabled:
   • When enrolling a Passkey, verification is always performed with their.
   • When enrolling a user selfie biometric, verification is always performed via
   • Template name
   • Policy name

📘

Enrollment Policy Configuration

Enrollment Policy configuration must be used if the user lacks both a biometric and a virtual passkey.

The "BioOnly" OIDC Policy for Authentication and Enrollment and the built-in Un-Managed (also known as Enabled) Enrollment Policy must only enroll biometric data. SSUI Managed Enrollment Policy is intended to be compatible with this feature.

3. Recovery: Users are allowed to add new devices and recover.

   • During recovery, identity verification is always performed.
   • During identity verification, users are shown the transaction template.

   

Once the parameters are updated, click Apply Changes.

Status: ON/OFF.

OpenID Settings

After creating this integration, it is presented with a Client ID and Client secret. These values will be used when configuring the identity provider connections on other platforms, and the Identity Portal does not save these values. Make sure to copy it or store it in your application if using the API endpoints.

• Connection Name: Name of the integration.
• Username Mapping: OIDC user claim (attribute) mapped to Verified Account ID for the user in the authID platform. It can be email, phone number, or username. Note that the allowed characters are listed below:
  • Upper and lower case letters (A-z), numbers (0-9)
  • Symbols: periods (.), hyphens ( - ), underscores ( _ ), the @ sign , hash ( # ), Circumflex accent ( ^ ), exclamation ( ! ) , tilde ( ~ ), grave accent ( ' )
  • See the screenshot of the experience using a phone number:

• Client Type: Public or Confidential. Public clients will not generate a client secret. Both can be used with or without PKCE.
• Require PKCE: Sets whether PCKE is mandatory to complete authentication. Public clients can be used without PKCE but this is not recommended.
• Support URL Encoded Email:

• Whitelist:
  • Allowed Login Redirect URLs: URLs used by the identity provider to handle login callbacks
  • Allowed Logout Redirect URLs: URLs used by the identity provider to handle logout callbacks
  • Well-known config URL: URL for OIDC document discovery. Contains URL endpoints for platforms that do not support document discovery

Click Apply Changes.

📘

Whitelist

If user know the domain name, user can generate redirect URLs for common scenarios for the major identity providers are discussed in this guide. If users are leveraging additional custom domains, these URLs must be separated by commas.

Session Settings

1. Cookie Settings

   1. Cookie Lifetime: The duration of the cookies that the user's browser receives after a successful authentication from the IDComplete OIDC Service. The user remains logged in if the cookie remains valid, meaning that authentication is not carried out (in that browser).
   2. Sliding Expiration: The authentication cookie's validity period is reset to the expiration timeout value when Sliding Expiration is enabled. If the user continues to browse after half of the delay has passed, this occurs.
   3. Keep Cookie on Browser Restart: It determines if the cookie is retained after a browser restart. If the corresponding parameter in the integration is not set, this value can be utilized.
   4. Access Token Lifetime: Token lifetime granted by the authID OIDC server to Okta, Auth0, and so on, OR the application if our OIDC is utilized as the main identity provider.
   5. Refresh Token: It makes it possible for the client application to obtain fresh access tokens without requiring the user to log in once more. If users are requesting the offline_access scope, you must provide this.
   6. Refresh Token Lifetime: Validity of the refresh token.

2. Error Responses

   1. OIDC Error Response: determines whether to send detailed error messages to the end-user or client application.

AMR Values

In support of RFC-8176, authID now returns Authentication Method Reference (AMR) values as part of the OIDC response to better support customers who need to know what authentication methods were used during the authentication process.

The following values will be returned for the appropriate scenarios:

• Face: When biometric verification (not enrollment) is performed.
• User: When a liveness check is performed during biometric verification or enrollment.
• hwk: When FIDO2 verification (not enrollment) is performed.
• SMS: When the verification link is sent via SMS transport.
• Email: It is a custom value outside of the RFC spec it is returned when the verification link is sent via email transport.

Connections

The created connections details are displayed under the Connections section.

Modify Connections

To modify the connection, follow the below procedure:

1. From the create connection grid table, click on the appropriate integration ID the Connection details screen displays,

2. Once the appropriate modification is updated click Apply Changes. A message displays as in the below screen

Delete Connection

To delete the connection,

1. From the existing connection grid table, click on the appropriate integration ID the Connection Details screen displays,

2. Click Delete Connection. The below message window displays.

3. Click OK to continue to delete the created or existing connections.
4. Click "Cancel" to cancel the "connections details" screen.

Video Walkthrough

The following video displays how to set up an OIDC connection in the Identity Portal.

](https://player.vimeo.com/video/790223856?h=4b134ba582)