Authorization is one of the most important aspects in modern applications. The issue of integrity, security and safety of personal data is one of the key issues in the development of almost any modern software.
Follow these streamlined steps for OAuth 2.0 deployment:
- Set up your IDP server using the provided document.
- Choose your authentication approach:
- Test implementation on HTML page.
IDP Setup
In this section, we'll explore configuring the Identity Provider (IDP) for streamlined integration with OAuth 2.0. Understanding this setup is crucial for establishing secure authentication and authorization.
Let's delve into the key steps for a robust access control framework.
To setup IDP:
Registration
Navigate to https://auth0.com.
Click Sign up on the top right and follow the on screen instructions to register your account.
Application Creation
Log into the account and click Application > Applications. The Applications page appears.
Click Create Application. The Create applications page appears.
Provide a name for the application and select the application type. Click Create, the Application's page appears.
Click Settings. The Settings tab appears.
The Basic Information section contains essential parameters for integrating with the IDP service in the Liveperson account. Note the two key parameters, Client ID and Client Secret.
Scroll below to the Application URL section.
Specify a whitelist of allowed addresses for authorization redirects. For local development with Angular, include the standard address to test the application on your computer.
ℹ️ Ensure all permitted addresses are added to pass authorization; omission may hinder the process.
Ensure all permitted addresses are added to pass authorization; omission may hinder the process.
Extract public key
Scroll to the bottom to Advanced Settings click Certificates.
This tab displays the certificate used for signing authorization requests. Copy and save the certificate as text or download it in your preferred format.
ℹ️ You can download the PKCS#7 format and drag and drop it in a browser to view and copy the text.
ℹ️ For IDP integration, the public key from this certificate is needed to validate tokens.
Next, click Endpoints tab. The Endpoints page appears.
You can find a list of available endpoints for working with the IDP server. For Liveperson integration, make a note of the "authorize" and "token" fields.
Run Sample Web App
You can create a sample web app that uses Auth0 as IDP to login to test out the configuration.
Find the sample app https://github.com/auth0-samples/auth0-angular-samples/tree/master/Sample-01
To install the sample app:
Open Terminal and run the following script.
git clone https://github.com/auth0-samples/auth0-angular-samples.git
cd auth0-angular-samples/Sample-01
npm install
Once run, locate the auth0-angular-samples folder on your computer.
The folder is usually located at Finder > Home > auth0-angular-samples.
Go to auth0-angular-samples folder > Sample-01 > auth_config.json.example.
Rename Sample-01 > auth_config.json.example to Sample-01 > auth_config.json
Next, navigate to Sample-01 > auth_config.json open it in an editor.
{
"domain": "{DOMAIN}",
"clientId": "{CLIENT_ID}",
"audience": "{API_IDENTIFIER}",
"apiUri": "http://localhost:3001",
"appUri": "http://localhost:4200",
"errorPath": "/error"
}
Replace API_IDENTIFIER with the API found in Application Details at Application > API.
Open auth0-angular-samples folder. Right click Sample-01 folder > New terminal at folder.
Run the following while in Sample-01 directory.
npm run dev
Ensure that you have Node.js installed on your computer before you run the command. You can download Node.js here.
If you still have issues with this run "npm audit fix --force" and press "y" when prompted.
Access http://localhost:4200 from a browser of your choice.
Click Log in.
Use Liveperson or Gmail to login. Click Accept.
It should redirect you to back to http://localhost:4200 with user info.
In summary, we successfully registered and established a basic application with an integrated IDP server, serving as an authorization server for Liveperson accounts. We have thoroughly explored the relevant tabs to gather essential information for configuring the integration.
Configure Flow
The two approaches are, Authorization Code Flow and Implicit Flow:
- Authorization Code Flow is a secure and recommended way of obtaining access tokens. It involves the following steps:
- The client app initiates the authentication process by redirecting the user to the authorization server.
- The user authenticates with the authorization server and grants permission to the client app.
- The authorization server returns an authorization code to the client app.
- The client app exchanges the authorization code for an access token.
- Implicit Flow is a simplified flow that is suitable for public clients, such as single-page applications. It involves the following steps:
- The client app initiates the authentication process by redirecting the user to the authorization server.
- The user authenticates with the authorization server and grants permission to the client app.
- The authorization server returns an access token to the client app.
The main difference between the two flows is that the Authorization Code Flow is more secure than the Implicit Flow. In the Authorization Code Flow, the client app exchanges the authorization code for an access token, whereas in the Implicit Flow, the access token is returned directly to the client app. This makes the Implicit Flow more vulnerable to certain types of attacks, such as token leakage and man-in-the-middle attacks.
Authorization code flow is recommended for secure client secret management, especially in front-end scenarios like SPAs or mobile apps. Utilize authorization code flow with PKCE to prevent client secret exposure.
Liveperson empowers clients with successful business tools, emphasizing the implementation of authorization and campaigns for authorized dialogs. Key benefits include:
- For Agents: First visit tracking, conversation history, access to personal information, and user role/status management.
- For Clients: Personalized service, messaging history access, and secure processing of sensitive data.
ℹ️ Specific details and configurations will be dependent on your unique setup. For a successful setup, please reach out to your dedicated LivePerson Account Manager.
Your LivePerson Account Manager will be able to assist you with any further configuration or customization required for your specific needs.
IDP Integration
Before proceeding with the integration setup, you should create an IDP server, an example of basic setup can be found in the right hand quick links section.
Now that we have the IDP server configured and we know all the necessary data, let's start configuring the integration.
Log into your Conversational Cloud account.
Navigate to Campaign Builder. The Campaign Builder page appears.
Click Data Sources. The Data Sources page appears.
In the Integrations tab, next to Consumer Identity Providers, click Configure. The Consumer Identity Provider page appears.
Scroll to the Configure identity providers auth settings. The form for setting up integration with the IDP server appears.
For Code Flow:
Select and where required provide the information as follows:
- OAuth 2.0 Authentication Type: Select one of the two available types of authorization process, in our case Code Flow.
- Authorization Code Flow with Proof Key of Code Exchange (PKCE): Enabling PKCE in the Authorization Code Flow enhances security by preventing code interception in native and mobile applications.
- Issuer Display Name: An arbitrary name you can give to this integration.
- JWT issuer (iss): IDP server domain (from IDP configuration).
- Authentication Endpoint: Url address for authorization endpoint (from IDP configuration).
- Token Endpoint: Since the Code Flow implies obtaining an authorized token on the server side, the “authorize” request alone is not enough. For these needs, the “token” request is used. In this field, you should specify the Url address of the “token” endpoint (from the IDP configuration).
- Client ID: Client ID can be found in your IDP base configurations (from IDP configuration).
- Client Secret: Client Secret can be found in the base configurations of your IDP (from the IDP configuration).
- Choose IDP Certificate Type: The two options are:
- Set JWT Public key: JWT Public Key is the field where you should enter the public key that will validate the signatures. The key can be obtained from the certificate assigned to your IDP server. On setting up an IDP service, you can find the section on where and how to download a certificate, and then how to extract a public key from it.
- Use IDP JWKS Endpoint: Alternatively, you can specify an endpoint with a set of public keys that will be used for validation.
- JS Method Name: The name of the handling function that will be implemented on the frontend side to start the authorization process.
- JS Context: The context where the function handler, for the start of the authorization process, will be located. By default, you can use the browser context root - window.
- LP Public Key: May be needed to check the validity of responses from the LP backend.
For Implicit Flow:
Select and where required provide the information as follows:
- OAuth 2.0 Authentication Type: Select one of the two available types of authorization process, in our case Implicit Flow.
- Issuer Display Name: An arbitrary name you can give to this integration.
- JWT issuer (iss): IDP server domain (from IDP configuration).
- Authentication Endpoint: Url address for authorization endpoint (from IDP configuration).
- Choose IDP Certificate Type: The two options are:
- Set JWT Public key: JWT Public Key is the field where you should enter the public key that will validate the signatures. The key can be obtained from the certificate assigned to your IDP server. In the <article> on setting up an IDP service, you can find the section on where and how to download a certificate, and then how to extract a public key from it.
- Use IDP JWKS Endpoint: Alternatively, you can specify an endpoint with a set of public keys that will be used for validation. Here you can read what JWKS is.
- JS Method Name: The name of the handling function that will be implemented on the frontend side to start the authorization process.
- JS Context: The context where the function handler, for the start of the authorization process, will be located. By default, you can use the browser context root - window.
- LP Public Key: May be needed to check the validity of responses from the LP backend.
Click Save. The information is saved and the integration is completed.
Once done, you can define engagements which require authentication, by going to Engagement Settings under the engagement flow.
For more detailed information on defining engagements, see Creating Engagements in Web Messaging.
Frontend Authentication
For Code Flow:
In the previous step, (For Code Flow - Form, point #10| For Implicit Flow - Form, point #6) it's indicated that for a web application, the handler function will be called during authentication.
According to this, in our front-end application, in the window context, a function that we named as lpGetAuthenticationToken should be defined.
In its simplest form, this function looks like:
window.lpGetAuthenticationToken(callback) {
callback({
ssoKey: <CODE>,
redirect_uri: <REDIRECT_URI>,
});
}
In this example, the business logic of how the <CODE> and <REDIRECT_URI> variables were obtained is omitted, as this may depend on which method of interaction with the IDP server is chosen and what the business logic is after receiving the authorization token.
Here is an example of one of the implementations of the authorization work applicable with an IDP server configured via auth0.com:
window.lpGetAuthenticationToken(callback) {
const code = window.getParameterByName('code');
const config = { redirectURI: <hardcoded_uri> };
if (!code) {
const url = window.authRedirect(config);
document.location.href = url;
} else {
const result = {
ssoKey: code,
redirect_uri: config.redirectURI
};
callback(result);
}
};
When executing this function, the presence of the query parameter “code” in the url line is checked. The variable config is determined as a hardcoded value, however, there may be separate logic or environment variables behind this.
Next, the code is checked. If there is no value at the code, then an authorization request is prepared and a redirect is made to this address, which will subsequently redirect back to the same page with the query parameter “code” added to the url line. If the code was found, then the else block will be executed in which the result will be prepared and passed through the callback function.
For Implicit Flow:
In the previous step, (For Implicit Flow - Form, point #6) it's indicated that for a web application, the handler function will be called during authentication.
According to this, in our front-end application, in the window context, a function that we named as lpGetAuthenticationToken should be defined.
In its simplest form, this function looks like:
window.lpGetAuthenticationToken(callback) {
callback(idToken);
}
Here is an example of one of the implementations of the authorization work applicable with an IDP server configured via auth0.com:
window.lpGetAuthenticationToken(callback) {
const token = window.getParameterByName('id_token');
const config = { redirectURI: <hardcoded_uri> };
if (!token) {
const url = window.authRedirect(config);
document.location.href = url;
} else {
callback(token);
}
};
When executing this function, the presence of the query parameter “id_token” in the url line is checked. The variable config is determined as a hardcoded value, however, there may be separate logic or environment variables behind this.
Next, the token is checked. If there is no value at the token, then an authorization request is prepared and a redirect is made to this address, which will subsequently redirect back to the same page with the query parameter “id_token” added to the url line. If the code was found, then the else block will be executed with the callback function and token as a parameter.
In summary, the key distinction in the frontend perspective is that in the implicit flow, we directly receive a JWT during authorization response, whereas in the code flow, we receive a code that is sent to the backend to obtain and authenticate the JWT for our session. Unlike the implicit flow, the code flow prevents potential theft of the JWT, making it preferable for implementation.
Testing
The HTML page for testing purposes on your local machine for Code flow can be downloaded here.
The HTML page for testing purposes on your local machine for Implicit flow can be downloaded here.
The HTML page for testing purposes of the unauthenticated flow can be found here.
Ready to move on? Click here to proceed.
