Skip to main content

Protect chatter data using verification and authentication

In some Answer flows, you may either serve chatters with sensitive data, or give them the chance to make changes to their account, orders, bookings, etc. In these cases, you want to make sure that the chatter is who they say they are first.

Verification and authentication are two methods that you can use, either alone or in conjunction with each other, to make sure you're not letting just anyone access or modify sensitive data:

  • Verification is the confirmation that a piece of data the chatter provides (name, email, phone number, etc.) matches the value in your database.

  • Authentication is the confirmation that the chatter is the person they claim to be, by asking them to sign into an account.

The approach you use depends on the sensitivity of the data or actions the chatter wants to access or perform. The higher the risk of data getting compromised, the stricter the verification and/or authentication processes should be.

Use verification to match chatter and database values​

There are two use cases for using verification:

  • When the chatter wants to access low-risk information, you can use verification on its own.

  • When the chatter wants to access higher-risk information, you can use verification in addition to authentication.

As a best practice, when you're using verification, you should make sure the chatter has two pieces of identifying information before giving them the information they're looking for. Identifying information can include things like:

  • Email

  • ZIP/postal code

  • Account number

  • Order number

  • One-time password

Set up a verification process​

Verification setup varies depending on the type of process you want to implement. However, it often looks something like:

  1. Get one or two pieces of information associated with the person you want to verify already saved in a variable. This information can come from an API, or from metaFields. For more information, see metaFields in Ada's developer documentation.

  2. Using a Capture block, ask the chatter to provide the information it already has.

  3. Using a Conditional block, verify whether the information the chatter provided matches the information your bot has. Then, create responses for both successful and unsuccessful matches.

After configuring your Answer flow this way, the bot only provides the info the chatter is looking for if those values match.

Use authentication to confirm a chatter's identity​

When chatters want to access sensitive information, or perform sensitive actions like making purchases, authentication is the best way to ensure the right person is doing it.

After authentication, you can also add verification to add an additional layer of security.

Set up an authentication process​

There are three ways we typically set up authentication. The method that's right for you might vary based on how your website works, but all of them accomplish the same general function: after the chatter authenticates, Ada saves an access token that you can then use in sensitive API calls. In all of these below cases, you'll see that authentication tokens either automatically expire or are saved in the Token Vault to keep them secure.

Authenticate using the Sign In block​

Ada has a built-in method of authenticating chatters. For information on how to configure authentication this way, see Let chatters sign into your website.

When a chatter signs in using this block, it saves a temporary token that you can use in the header in the API call where you request information, as pictured below. This access token expires within a set time limit, which is determined by the authentication holder/client, or at the end of a conversation - whichever comes first.

Authenticate using a custom setup​

If the Sign In block approach doesn't work for your authentication method, you can work with your Ada team to create a custom method to save your chatter's access token. Typically, there would be two ways we would handle this token:

  • Store the token in the Token Vault, and then access it using a token variable

  • Pass the token to the bot using sensitive metaFields in Embed

Authenticate server-to-server​

Another option to authenticate chatters is to store static credentials in a token variable.

  1. Format the credentials as follows, where the email is followed by the password, separated by a colon: [email protected]:p@ssW0rd.

  2. Encode that string into Base64. In this case, our encoded value is ZXhhbXBsZUBhZGEuc3VwcG9ydDpwQHNzVzByZA==. Then, save that string in the Token Vault.

  3. When creating your API call, in the header, make sure you precede the token with "Basic" and use a sensitive variable to populate it.

In this case, the token is static and doesn't expire, but it will stop working if the account credentials change (for example, if the password expires).

Have any questions? Contact your Ada team—or email us at .