Custom chat login

Updated

Here are the technical details for implementing secure end-user login to Kundo Chat. Contact us at support@kundo.se for further help with how it works.

You will need a REST endpoint that we can load via ajax, which then returns a signed token (JWT) with the user's information.

Note! It is not possible to combine the "chat assistant" function and custom chat login in the current version.

Specification for token

To verify that the user's information comes from you, you must sign a JWT token. JWT is a standard and there are ready-made libraries to generate these for all major programming languages. The jwt.io page is a great resource for how to create a JWT token.

The token must also meet the following specifications:

  • Be signed with the key Kundo provides, with the algorithm HS512 or HS256
  • Include name and email as claims. These are displayed to user and the editor.
  • Include an iat claim. We verify that it is not issued with a timestamp in the future.
  • Include an exp claim. We verify that it has not expired, even during continued communication during the chat. We therefore recommend that you set it to one hour after iat.

In addition to this, your token may contain optional claims, here things like customer number, user ID or other customer-specific parameters may be of interest to you.

Specification for the transport

The chat script makes a GET request to the URL you provide. Upon successful authentication of the user, you must respond with a JSON response containing the user's token above as the attribute "jwt".

A valid response, given my credentials and the imaginary key "kundo" would be  { "JWT": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE0ODAwNzM4NzksImV4cCI6MTQ4MDA3NzQ3OSwiZW1haWwiOiJhbHZpbkBrdW5kby5zZSIsIm5hbWUiOiJBbHZpbiBMaW5kc3RhbSJ9.YcCBANpzEoITTBpuMYiusprjFJbPo9207pAwwKZebS8"}. 

CORS

If the authentication endpoint and the page on which the chat is displayed are on different origins, your server must handle CORS headers for the communication to work.

Mozilla has good information (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS), which can be summarized as:

You must ensure that you answer with the Access-Control-Allow-Origin header that matches the origin from which the request comes, so that the chat script can read the contents of the answer. Here it is important to remember not to whitelist the entire internet but only the origins you trust, as otherwise it could expose the user's data.

In order to be able to send the user's identity to your authentication endpoint, we must make a call withCredentials, so that cookies and any client certificates are sent with. Because of this, a preflight-request is sent by the browser. It thus means an OPTIONS call to the same url, which must answer with Access-Control-Allow-Credentials: true-header.

Your endpoint should therefore support GET and OPTIONS to the same url, and suggest including the following headers in all of these (where <origin> is current, whitelisted origin):

Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

What does Kundo need?

To get started, we need a URL to your endpoint above, the signing key, and any extra fields that you want to be shown to editors.

We need to add these settings for the chat flow, then it will be used for all pages where the chat flow is entered. You also have the opportunity to choose whether the chat should always be logged in or whether it should be different on different pages.

warning Created with Sketch.