This guide provides essential information about the upcoming transition from OAuth 1.0 to OAuth 2.0 for authenticating with LivePerson APIs and how it affects your functions.

LivePerson will officially deprecate OAuth 1.0. After this all LivePerson will only accept OAuth 2.0 and existing OAuth 1.0 support will be turned off.

Automatic Migration and LpClient

The FaaS V2 platform is designed to make this transition as seamless as possible. LpClient, now only performs OAuth 2.0 authentication no longer OAuth 1.0.

  • Automatic Provisioning: During the automatic migration of your functions from FaaS V1 to FaaS V2, the platform automatically provisions new OAuth 2.0 credentials for your account.
  • LpClient Integration: The LpClient (part of the core-functions-toolbelt) is already configured to use these new OAuth 2.0 credentials by default.
  • Api Changes: Please be aware that some of the APIs that you may consume via the LpClient will require changes. Also today there may be APIs with limited or none existing OAuth 2.0 support

API Version Changes and Parameter Updates

It is crucial to be aware that migrating from OAuth 1.0 to OAuth 2.0 is not just a change in authentication methods but can also involve changes to the APIs themselves. Some LivePerson APIs have distinct versions that are tied to a specific authentication method. When you switch to OAuth 2.0, you may also need to update your code to call a newer version of an API endpoint. A prominent example is the Messaging Operations API.

  • API: Messaging Operations API
  • Version 1 (Legacy): This version of the "Current Queue Health" API exclusively supports OAuth 1.0.
  • Version 2 (Current): This version exclusively supports OAuth 2.0.

When migrating, you cannot simply switch the authentication and continue using the v1 endpoint. You must update your function to call the v2 endpoint, which may also require providing additional or different request parameters.

Always consult the API documentation for the specific endpoints your functions use to verify the correct version and required parameters for OAuth 2.0 authentication.

Handling Custom Application Keys

If your functions use a custom application key (e.g., one with a specific, restricted permission set), you are responsible for migrating it to OAuth 2.0. You must manually obtain new OAuth 2.0 credentials for your custom application and update your functions to use them.

FaaS V2 Frozen Functions

Functions running in compatibility mode (i.e., automatically migrated V1 functions that have not been edited) will behave as follows:

  • With Custom OAuth 1.0 Secrets: If the function is configured with a custom OAuth 1.0 key, it will continue to use that key.
  • Without Custom Credentials: If the function does not use a custom key, it will attempt to use the new, platform-provided OAuth 2.0 credentials where possible. For APIs that only support OAuth 1.0, it will fall back to using the legacy OAuth 1.0 keys.

Manually Upgraded FaaS V2 Functions

When you manually edit a function's code, it is no longer considered to be in compatibility mode. At this point, you are responsible for ensuring your function uses the correct authentication method.

  • Recommended Path: Update your code to use OAuth 2.0 credentials. This is the most secure and future-proof approach.
  • Discouraged Alternative: For temporary backward compatibility, you can explicitly configure your client to use an OAuth 1.0 key. However, this is strongly discouraged, as it will cease to function after the deprecation date.