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
Customer Web App
Customer Token Endpoint (Mandatory for Code Flow)
Example Request:
POST /oauth2/v3/token HTTP/1.1 Host: www.customer.com Content-Type: application/x-www-form-urlencoded code=3shshs92jsls/snxbxismNSsgHSVb& client_id=8819981768.lp-integration.customer.com& client_secret=fafadshdjkf943yehsjhed& redirect_uri=https://www.liveassist.com/oauth2/code_redirect& grant_type=authorization_code
Example Response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}
The id_token in the response is standard JWT and can be translated to the unpacked form. Here is an example of the unpacked id_token:
{
"iss": "www.customer.com",
"sub": "fdskjfd-user-id-3773hshshs",
"exp": “1353801026”,
"iat": "1353601026”,
"email": "user@gmail.com”,
"picture": "http://www.customer.com/pics/fdskjfd-user-id-3773hshshs”
}
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.
Other Topics
See:
- High Level Software Architecture: Authenticated Interactions with OAuth 2.0—Prerequisites
- High Level Software Architecture: Authenticated Interactions with OAuth 2.0—How It Works
- High Level Software Architecture: Authenticated Interactions with OAuth 2.0—Detailed API