Customer Authentication enables consistent and personalized conversations across channels and over time. The authentication requirements consist of two main elements:
  1. A customer identifier
  2. An access token
The source, format, and use of these items depends on the customer’s infrastructure and services.  However, where applicable and feasible, ASAPP instills a few direct requirements for integration of these components. This section outlines the requirements and considerations in the sections below. Integrations leveraging customer authentication enable two main features of ASAPP:
  1. Combination of the conversation history of a customer into a single view to enable the true asynchronous behavior of ASAPP.  This allows a customer to come back over time as well as change communication channels but maintain a consistent state and experience.
  2. Validation of a customer and make API calls for a customer’s data to display to a representative or directly to the customer.  
The following sequence diagram depicts an example of a customer authentication integration utilizing OAuth customer credentials and a JSON Web Token (JWT) for API calls.
Customer authentication integration sequence diagram showing OAuth credentials and JWT token flow for API calls

​
Identification

​
What is a Customer Identifier?

A customer identifier is the first and most important piece of the Customer Authentication strategy. The identifier is the key element to determine:
  • when to transition from unauthenticated to authenticated
  • when to show previous conversation history within chat
When a customer returns with the same identifier, the customer sees all previous history within web and mobile chat. These identifiers are typically string values of hashed or encrypted account numbers or other internal values. However, it is important to not send identifiable or reusable information as the customer identifier, such as their actual unprotected account numbers or PII.

​
Customer Identifier Format

The customer may determine the format of the customer identifier. The ASAPP requirements for the customer identifier are:
  • Consistent - the same customer must authenticate using the same customer identifier every time.
  • Unique - the customer identifier must represent a unique customer; No two customers can have the same identifier.
  • Opaque - ASAPP does not store PII data. The customer must obfuscate the customer identifier so it does not contain PII or any other sensitive data. An example of obfuscation strategy is to generate a hash or an encrypted value of a unique user identifier (e.g. user ID, account number, or email address).
  • Traceable - customer-traceable but not ASAPP-traceable.
    • The customer must be able to trace the customer identifier back to a user. However, it cannot be used by ASAPP, or any other party, to trace back to a specific user.
    • The reporting data generated by ASAPP includes the customer identifier. This reporting data is typically used to generate further analytics by the customer. You can use the customer identifier to relate ASAPP’s reporting data back to the actual user identifier and record on the customer side.

​
Passing the Customer Identifier to ASAPP

Once a customer authenticates a user on their website or app, the customer must retrieve and pass the customer identifier to ASAPP ( typically via the SDK parameters) as part of the conversation authentication flow. You can find more details for your specific integration in the following sections:

​
Tokens

While they are not a hard requirement for Customer Authentication, tokens play an important part in the overall Customer Authentication strategy. Tokens provide a way of securely wrapping all communication between Customers, Customer Companies and ASAPP. You can achieve this when you ensure that every request to a server is accompanied by a signed token, which ASAPP can verify for authenticity. Some of the benefits of using tokens over other methods, such as cookies, is that tokens are completely stateless and are typically short-lived. The following sections outline some examples of token input, as well as requirements for their use and validation.

​
Identity Tokens

Identity tokens are self contained, signed, short-lived tokens containing User Attributes like Name, User Identifiers, Contact Information, Claims, and Roles. The simplest and most common example of such a token is a JSON Web Token, JWT. JWTs contain a Header, Payload and Signature. The Header contains metadata about the token, the Payload contains the user info and claims, and the Signature is the algorithmically signed portion of the token based on the payload. You can find more information about JWTs at https://jwt.io/. Example JWT: 
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

​
Bearer Tokens

A Bearer Token is a lightweight security token which provides the bearer, or user, access to protected resources. When a user authenticates, a Bearer Token type is issued that contains an access token and a refresh token, along with expiration details. Bearer tokens are short-lived, dynamic access tokens that can be updated throughout a session using a refresh token. Example Bearer Token: 
{
  "token_type":"Bearer",
  "access_token":"eyJhbGci....",
  "expires_in":3600,
  "expires_on":1479937454,
  "refresh_token":"0/LTo...."
}

​
Token Duration

Since every token has an expiration time, you need a way for ASAPP to know when a token is valid and when it expires. A customer can do this by:
  • allowing decoding of signed tokens.
  • providing an API to validate the token.

​
Token Refresh

You need to refresh expired tokens on either the client side, via the ASAPP SDK, or through an API call.  You can find SDK token refresh implementation examples at:

​
Token Validation

You need to validate tokens before you can rely on them for API access or user information. Two examples of token validation are:
  • Compare multiple pieces of information - ASAPP compares a JWT payload against the SDK input of the same attributes, or against response data from a UserProfile API call.
  • Signature Validation - ASAPP can also validate signatures and decode data if needed. This would require sharing of a trusted public certificate with ASAPP.

​
Omni-Channel Strategy

One of the key capabilities of the ASAPP backend is that it supports customer interaction via multiple channels - such as chat on web portals or within mobile apps. This enables a customer to migrate from one channel to another, if they choose, within the same support dialog. In order for this to function, it is important that the process of Customer Authentication be common to all channels. The ASAPP backend should obtain the same access token to access the Customer’s API endpoints regardless of the channel that the customer selects. If a customer switches from one channel to another, the access token should remain the same.

​
Testing

You need a comprehensive testing strategy to ensure success. This includes the ability to exercise edge cases with various permutations of test account data, as well as utilize the customer login with direct test account credentials.  Operationally, the customer handles customer login credentialing; however, ASAPP requires the ability to simulate the login process in order to execute end to end tests.  This process is crucial in performing test scenarios that require customer authentication. Corollary, it is equally important to ensure complete test scenario coverage with different types of test-based customer accounts.