Integration to an IDP via OIDC

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.

Image alt text](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:

The San Juan Mountains are beautiful!

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.

The San Juan Mountains are beautiful!

OpenID Settings

After creating this integration, the user is presented with a Client ID and Client secret. These values are used when configuring the identity provider connections on other platforms, and the Identity Portal do not save these values. Be sure to copy them or store them in the user application if using the API endpoints.

The San Juan Mountains are beautiful!
  • 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:
The San Juan Mountains are beautiful!
  • Client Type: Public or Confidential. Public clients do 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 it is not recommended.
  • Whitelist:
    • Allowed Login Redirect URLs: URLs that handle login callbacks for the identity provider.
    • Allowed Logout Redirect URLs: URLs that handle logout callbacks for the identity provider.
    • 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. It contains URL endpoints for platforms that do not support document discovery.

πŸ“˜

Whitelist

If user know the domain name then the user can generate redirect URLs for common scenarios for the major identity providers that 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

The San Juan Mountains are beautiful!
  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 can 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.