AuthID Integration

Overview

Configuring authID's backend and user preferred identity provider are the two separate locations need to 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 walk through the process of creating an integration within authID.

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)

Identity Portal

Although some users prefer to use the API endpoints to generate an OIDC integration within authID's backend system, this guide cover 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:

Connection Settings

Access Policy

This page contains plainly worded explanations of the various scenarios that a user might encounter and the desired behavior of the OIDC connection.

OpenID Settings

After creating this integration, you will be 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. Be sure to copy them or store them in your application if using the API endpoints.

• Name: name of the integration
• Username Mapping: OIDC user claim (attribute) mapped to Verified Account ID for the user in the authID platform. 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.
• 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
  • Connection ID: Internal ID of the connection
  • API Key ID: ID of the API key for the connection
  • Client ID: Client ID is used for connecting other platforms
  • Well-known config URL: URL for OIDC document discovery. Contains URL endpoints for platforms that do not support document discovery

📘

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.

Okta

Domain name:

Login Redirect URL:

https\://{YOURDOMAIN}.okta.com/oauth2/v1/authorize/callback.

Logout Redirect URL:

https\://{YOURDOMAIN}.okta.com

Auth0

Domain name:

Login Redirect URL:

https://{YOURDOMAIN}.us.auth0.com/login/callback

Logout Redirect URL:

https://{YOURDOMAIN}.us.auth0.com

Workspace ONE

Domain name:

Login Redirect URL:

https://{YOURDOMAIN}.workspaceair.com/federation/auth/response/oauth2

Logout Redirect URL:

https://{YOURDOMAIN}.workspaceair.com

PingIdentity

Domain name:

Login Redirect URL:

https://auth.pingone.com/{EnvironmentId}/rp/callback/openid_connect

BeyondTrust

Please see the BeyondTrust walkthrough for information on the Login Redirect URL.

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.