Introduction

With Authenticated Customer Information, consumers that have logged into your website or app and initiated a chat display as being authenticated. Microsoft Dynamics then displays, in real-time, the correct and verified information of the authenticated contact in the Contacts Record database. Agents are able to easily identify which consumer data is authenticated in the CRM, and which has arrived from the page.

All authenticated customer information is encrypted and transferred over SSL, using the OAuth 2.0 and OpenID Connect standards, using a JSON Web Token. This ensures that your customers’ data stays safe and cannot be manipulated.

Authenticated Customer Information gives brands the confidence that each consumer is verified as being who they say they are, and that the relevant data for a personal conversation is available to the agent.

See the following description of the main components and high level architecture of the consumer SSO solution for Live Assist for Microsoft Dynamics 365 messaging and chat, for both mobile and web.

Why use Authenticated Customer Information?

Authenticated Customer Information facilitates the following:

It increases the security of the communication, as the customer’s identity is verified.

It increases the efficiency of agents, and ensures that each consumer receives a personalized service.

It enables brands to expand the types of services they offer to consumers during conversations, for example:

Making purchases easier for existing consumers: once the consumer has logged into the brand's website, Live Assist automatically brings the consumer's PII to the agent workspace, including the account number, package details, billing history, and other relevant account information. The conversation can immediately proceed to the new purchase, without the consumer having to identify themselves or make explanations about their account. The agent can manage the inquiry quickly, as they do not have to open another application to get the information they need.

Facilitating billing and payment conversations: once the consumer has logged into the brand’s website and started a conversation with an agent, the agent can quickly identify the most cost-effective way for the consumer to pay, according to the PII exposed during the authenticated chat.

Terminology

OAuth 2.0: A standard way in which a user (referred to as Resource Owner) of one service (referred to as Resource Server) can delegate credentials to another service (referred to as Client Application). In this case, the client application is the Live Assist service, the resource server is the authentication service of the customer, and the user/resource_owner is the customer of the customer (the consumer).

OpenID Connect: A simple identity layer on top of the OAuth 2.0 protocol. In this case, the user delegates the access to their identity properties to the other service. OpenID Connect has been adopted by numerous companies including Google, Cisco, RSA, Verizon, PayPal, PingIdentity, and Symantec.

OAuth 2.0 code: In some flows, instead of directly receiving the access_token, the authentication server provides a code which can be used only along with other secret information in order to get the access token. This way, the intermediator that passes the OAuth 2.0 code is not able to gain access to the data.

Code Flow: An authentication flow in which the Live Assist service gets the authentication assertion directly from the customer authorization server. In OAuth 2.0, this flow is implemented using the OpenID Connect Code Flow. This flow is also called server-to-server flow, or simply server flow.

Implicit Flow: In this flow, the Live Assist service does not get the authentication assertion directly from the customer server, but through the user. The assertion is signed by the customer authorization service, and is optionally encrypted using the Live Assist service key. In OAuth 2.0, it is implemented using the OpenID Connect Implicit Flow. This flow is also called client flow or envelope flow.

Principles

Industry Standards

The solution is based on two industry standards: OAuth 2.0 and OpenID Connect. For OpenID, Connect, Code Flow, and Implicit Flow are used. These flows are described in a section of the OpenID Connect specification.

Google OpenID Connect is used as a reference implementation for the Code Flow. This means that the Live Assist solution is built and tested against Google OpenID Connect servers. Our beta environments use the Google Identity provider for our end-to-end tests. Customers should follow the Google identity response format to use the Live Assist authentication service.

Major Components

Customer Mobile App

The customer mobile app is responsible for user authentication against the brand servers. In order to use the Live Assist services, it uses the Live Assist Messaging SDK. Upon opening the communication socket by the SDK, the Live Assist backend detects whether the account requires authentication. If authentication is required, the SDK will ask the mobile app to supply an OAuth 2.0 code or JWT (depending on the specific flow). The specific way that this response is generated depends on the brand’s decisions. A common implementation method is to request the customer server to generate such a response based on the user credentials that were given during the login phase.

Customer Web App

The customer web app is very similar to the mobile app, except that it runs on a browser. It embeds the Live Assist Web SDK, and acts in the same way as described above for the mobile app. The web app can display the embedded window originated by the Live Assist SDK, or open a Live Assist popup window to interact with the consumer. When the Live Assist embedded window is set to pop-out mode, the authentication must take place using a page redirect mechanism.

Customer Token Endpoint (Mandatory for Code Flow)

This endpoint implements the standard OpenID Connect token endpoint. This API accepts a valid OAuth 2.0 code along with the clientID and secret information. It should then respond with validation approval that contains some of the user’s basic information, encoded and signed as a JWT and access_token for further inquiries.

Live Assist SDK

This is a Live Assist layer embedded into the customer app (mobile/web). It mediates between the app and the Live Assist Service and provides the interaction conversation UI. This layer calls the mobile app to supply an OAuth 2.0 code whenever the Live Assist service needs it.

Live Assist Service

This is the Live Assist service used for interaction between the customer agent and the consumer. In the authentication flow, this server consumes the OAuth 2.0 code and then exchanges it with the customer token endpoint for access_token and id_token using the token endpoint. The service might also ask the userinfo endpoint for complementary information using the access_token.