Authentication
Identify your users, eliminate impersonation, send custom data and more
TL;DR
The Long Version
Collecting User Data
If you want to support non-logged-in users, this is the way to go.
Setting collectUserData
to true
will prompt the user to input a name
and email
before proceeding to chat.
Since any user can input any email, the user is considered non-verified
and only has access to previous chats that were created on their device.
Programmatically Passing User Data
If your user is logged-in and you have their details, you can programmatically send user data in one of two ways:
From the Client/Browser
This method is sufficient in most cases, but is still considered non-verified
because malicious users can intercept outgoing requests and impersonate someone else.
Any customData
sent in this method will be saved as non_verified_custom_data
so that it can be used with caution.
Similar to other non-verified
methods, the user only has access to previous chats that were created on their device.
Server to Server
This is the only truly secure way of authentication; User data are sent from your server to ours, we save that data and give you back a token that can be used in the widget config.
Since this is a verified
method, the user has access to all previous chats regardless of which device they were created on, as long as they were created through this verified
method.
For more details on what also can be passed when authenticating a user, see the API reference.
Anonymous (No Authentication)
This could only be useful if you do not care who your users are, or if you’re testing the widget.
Naturally, the user only has access to previous chats that were created on their device.
Workspace Management
If you support multiple workspaces—in your dashboard or website—per user, you can pass the user’s workspace id. This way, sessions will be scoped by that externalId
.
This works regardless of the authentication method you use (verified
or non-verified
).
Was this page helpful?