Consumer Identity Provider

To define the OAuth 2.0 authentication:

  1. In Conversational Cloud, go to Management Console

  2. Search for "Consumer Identity Provider"

Search for Consumer Identity Provider in the Management Console

  1. Click on 'Click to configure'

Click to configure the Consumer Identity Provider

  1. In section #2 - "Define Identity Provider", select the preferred oAuth 2.0 Authentication Type, and then complete the required fields

Select consumer authentication type

The following parameters should be defined:

  • OAuth 2.0 Authentication Type - Implicit / Code Flow

  • OAuth 2.0 Authentication Endpoint - An HTTPS URL that used in the case that the consumer conversation window is configured as a Seperate Browser Window.

  • OAuth 2.0 Token Endpoint - An HTTPS URL that used in Code Flow

  • Choose IDP Certificate Type - JWT Public Key / JWKS Endpoint

  • OAuth 2.0 Client ID - Used in Code Flow

  • OAuth 2.0 Client Secret - Used in Code Flow

  • JS Method Name - When Conversational Cloud embedded window is used in Web

  • JS Context - When Conversational Cloud embedded window is used in Web

RFC Compliance

There are actually 2 versions to our Auth service - the "openID" (backwards compatible - default) version, and the "OAuth 2 RFC" (non default) version. If you already have a working consumer identity provider configured - chances are you're working with the "openID" version. If you're setting up a consumer identity provider for the first time - chances are you want the "OAuth 2 RFC" version.

Starting with version 9.3.0 of the Unified Window (May 2018) - all newly created consumer identity providers will use the "OAuth 2 RFC" version by default.

What's the difference

There are some small changes in the flow/implementation. All changes are only relevant to External windows and the way they interact with the Authentication Endpoint and the Token Endpoint:

  • In the "openID" version (External window) we call the Authentication Endpoint with a "redirect_uri" query parameter that redirects to the external window, and it contains encoded query parameters that the window needs. In the "OAuth 2 RFC" version the "redirect_uri" query param is clean and contains no query params of its own. What we used to pass as query parameters we now pass as a separate encoded "state" query parameter, which is parsed by our external window. To support this - the Authorization Endpoint must pass the "state" query param which it receives to the external window as is.

  • In the "openID" version (External code flow) we pass a single redirect_uri to the Token Endpoint (either provided by the customer page or "https://liveperson.net" by default), while the Authorization Endpoint uses the redirect_uri to redirect to the external window. In the "OAuth 2 RFC" version we always pass the location of the external window as the redirect_uri - to both the Authorization Endpoint and the Token Endpoint.

  • In the "openID" version (External implicit flow) we call the Authorization Endpoint with a query parameter "response_type=token" to denote that it's implicit flow and we expect to receive a JWT. In the "OAuth 2 RFC" version we use "response_type=id_token".

How to use the "OAuth 2 RFC" version for old connectors

Please contact your account team at LivePerson support.

Brand's Authorization Service Implementation

The brand's Authorization Service should have to register configuration of LivePerson’s authentication client:

  • LP-clientID

  • LP-clientSecret (when Code Flow is used)

  • LP Popup redirect URI (when external web window is used)

  • LP-Public key (when Implicit Flow with encryption is used)