How to authenticate your customers with Zowie?

Business Context

A high deflection/containment rate of automation can be supported by introducing personalized automation via integrations with systems (CRM, ecommerce, subscription, logistics platforms, etc.) to access user information. These integrations may require a specific end-user recognition/authentication process. This document describes recommended solutions you may adopt in our partnership.

Definitions

Levels of end-user recognition

We distinguish the following types of end-user recognition when they are interacting with chat/email automation:

1. Anonymous - we don’t know who the person is.
2. Recognized - by collecting specific information (e.g., email address, order number, postal code, etc.), we can use a System to verify whether this information matches the same User profile to confirm the identity. Once identity is confirmed, we can act on behalf of a recognized User using System Token.
3. Authenticated - thanks to using an authentication mechanism (oAuth2.0, stateful, stateless tokens, etc.), we can authenticate a User and use the same mechanism to act on behalf of an authenticated User using User Token.

Authentication Methods

Zowie can support multiple different authentication methods. We’re ready to align with your specific requirements. We’re also sharing examples of recommended authentication methods.

Stateless authentication via token

Stateless authentication via JWT tokens easy-to-implement mechanisms that can be used to authenticate Users and act on behalf using API.

Configuration:

1. Generate a pair of keys - private and public keys.
2. Share only the public key with Zowie so we can verify the signature of a token.

Process

1. User is authenticated within your System(s).
2. Your System will generate a JWT token using a private key and pass it as an accessToken field to Zowie’s chat instance.
3. Zowie receives a JWT token and uses the public key to verify the signature and authenticate a User. Successful verification grants the User access to the history of previous conversations.
4. Zowe can keep the received JWT token in the context, which can then be used in any API calls as User Token to pull/push data from your System(s) eg. checking an order status or cancel an order.
5. (optional) This mechanism can be extended, and eg. JWT token may be exchanged to User Token.

Stateful authentication via token

The alternative to stateless JWT tokens is to use a stateful mechanism, which requires you to prepare an endpoint for token verification.

Configuration:

1. Prepare the API endpoint which allows Zowie to verify received a token. This endpoint should receive a token and respond with minimum user data eg. ID, email.
2. Share documentation for the API endpoint so that Zowie can integrate with the verification mechanism.

Process:

1. User is authenticated within your System(s).
2. Your System will generate a random token for this User, which we can verify via the provided verification endpoint.
3. Zowie receives a token and uses the verification endpoint to authenticate a User. Successful verification grants the User access to the history of previous conversations.
4. Zowe can keep the received token in the context, which can then be used in any API calls as User Token to pull/push data from your System(s), eg. checking an order status or canceling an order.
5. (optional) This mechanism can be extended, and e.g. JWT token may be exchanged for a User Token.

Authentication via oAuth 2.0

If your System(s) support granting access to API via oAuth 2.0 we’re ready to enable this support for your Users at Zowie as well.