There are scenarios where you would want to query your service from within the Kaizala card. While the APIs to be queried are public (without any authentication), you could query them directly. But, in case you want to secure your APIs to make sure the calls are made by the particular user from within the Kaizala card alone – you could use the Integration Service token. This post explains how you could generate this token and subsequently validate this on the service side.

Generating the Integration Service token

To generate the Integration Services token from within the card, you will need to call the method getIntegerationServiceToken exposed in the SDK (KASClient.js). Below is the screenshot of the API and the result printed from the developer tools console.

You could now pass this in your call to the API (as a header / in the body).

Validating the token

In order to identify if the API request is genuine, you will need to validate the token. This could be done by calling into the v1/users/me endpoint with the token as the accessToken in the header. Integration Service token’s validity is 30 mins.

This would give you the below details:

1. id – Kaizala user id, a guid to identify the user
2. name – name set by the user in the profile
3. phoneNumber – phone number of the user
4. pictureUrl – link to the profile picture
5. actionPackageId – Id of the Kaizala card / action package from which the token was generated

You could then use this on the service side to validate if the token to authenticate / authorize the request.

Hope that was helpful. Let me know if you have any questions through the comments section. Thank you for reading!

APPENDIX

APPENDIX A – Calling business systems from Kaizala custom action

When you want to make a call to a business system (e.g. LOB applications, 3rd party applications), the auth mechanism needs you to provide a token, app secret and probably other info. While you may be able to call a service by providing these details from the custom action, it could compromise your system.

In this case, you will need to cache the credentials, token and other secret information in the custom action (client side) which could be leaked by sniffing / compromising the client – which will then allow the intruder to compromise your system.

In order to make this call, you could secure the required call by building an adapter service that makes this call. That way, the secrets are on the service (which wouldn’t be compromised) and you could secure the adapter service by using the Integration service token (discussed in this post above). Below image gives an idea of how that system would look.