本文是针对Zendesk管理员亚博s. For information on the tasks required for developers, seeEnabling authenticated visitors.
This article includes the following topics:
About end user authentication for web and mobile messaging
End-user authentication is, simply put, verifying the identity of an end user. The verified end user’s new messaging request can then be connected with their past conversations, allowing agents to better support them.
This section includes the following topics:
Understanding key elements
To understand how end user authentication for messaging works, you should be familiar with the key elements involved in the authentication process:
- JSON Web Tokens (JWT) for authentication. Zendesk uses signed JSON Web Tokens (JWT) for authentication in messaging. These tokens verify the identity of the end users. Seejwt.iofor detailed information on JWTs.
- Signing key.A signing key is created by a Zendesk admin in Admin Center, and shared with your developer, who will then use it to sign the JWT as necessary. SeeCreating and sharing the signing key.
- Unique user identifiers, or external ids. These are alphanumeric strings (usernames or customer ID numbers, for instance) that are unique to each user.
- User name(optional). Including the name may help agents communicate with end users. If this information is collected and included in the JWT, it will appear in the Agent Workspace. However, it is not required.
Overview of the setup process
To enable end-user authentication, your Zendesk Admin first needs to create the signing key in Admin Center and provide this key (which will contain a secret) to your developer. Your developer will then need to implement a service on your business' back-end that can create the signed JWT and return this to your website or mobile app when requested (steps 1 and 2 in the image below). Any time your user is logged in to your website or app, your developer will need to call an equivalent login API which will be provided in both the Zendesk Web Widget and the Mobile SDKs. At sign-in time, the JWT will be passed to Zendesk in order to verify the claimed identity of the user (step 3 in the image below).
How the end-user and agent experiences are impacted
Once authentication for messaging is implemented, end users and agents will see slight changes in their experiences:
- 最终用户: Once they have been authenticated and their identity has been verified with Zendesk, the end user will not be prompted to provide their name or email address by the messaging bot as part ofthe default messaging response.
- Agents: Verified end users will be identified in the Agent Workspace by an authentication icon:
The agents will be able to view the external id as part of the end user's profile.
If the external id provided with the API matches the external id of an existing user, the messaging ticket will be referenced against the existing end user.
When an end user authenticates:
- A new end user will be created.The messaging ticket of the anonymous user will be associated with the newly-created user with the external id.
- If the authenticated end user has a non-closed messaging ticket, that ticket will be updated with the new messages.
- When an end user signs out, a new end user and new messaging ticket will be created for the subsequent conversation.
For example:
- End user A sends a message without signing in. User 1 and Ticket 1 is created.
- End user A signs in mid-conversation. User 2 is created with an external id (if no user with the external id exists).
- Conversation continues in Ticket 1 and the requester is updated to User 2.
Forreturningauthenticated users, there’s a background ticket merge to ensure conversational continuity. For example:
- End user A has an open Ticket 1 as an authenticated user.
- End user A logs out.
- End user A sends a message without signing in. User 2 and Ticket 2 are created.
- End user A signs in again mid-conversation. Authenticated User A is retrieved via the external id and the anonymous and authenticated conversations are merged.
- Conversation continues in Ticket 1 and Ticket 2 is closed.
SeeWorking with authenticated end users in the Zendesk Agent Workspace.
Creating and sharing the signing key
As mentioned in the section above, a Zendesk administrator must create a signing key and share it with the developer for use in the JWT. You can store up to 10 keys. Creating a signing key also enablesmessaging metadata variablesin Flow Builder.
To create and share a signing key
- InAdmin Center, click
Accountin the sidebar, then selectSecurity > End user authentication. - Click theMessagingtab, then click theCreate keybutton. If you are creating your first key, this button appears at the bottom of the page; if you have previously created a key, it appears in the top-right corner.
- In the Create new key dialog, enter an identifying name for the key, then clickNext.
- In the Copy shared secret dialog, clickCopyto save the secret to your clipboard, then clickHide key forever.
You’re returned to the Messaging tab, where the new key appears in the signing key list with the first six characters of the secret shown.
- Confidentially send the key ID and the shared secret key to your developer, who can then use it to create the JWT. SeeEnabling authenticated visitorsfor more information.
If you generate a new key but have reached your 10-key limit, a notification appears, asking you to delete any unused keys.
To delete an unused key
- InAdmin Center, clickAccountin the sidebar, then selectSecurity > End user authentication.
- Click theMessagingtab.
- Hover over the key you want to delete, then click the option menu icon and select删除.
- Confirm the action by clicking删除key.
Current limitations
The following limitations apply to the current version of end-user authentication in messaging:
- Restricted Guide articles.Guide articles that require authentication will not be available to users initially, even if they are authenticated. We will make additional improvements to the messaging product to enable users to view Guide articles that require user authentication. Articles that do not require user authentication are not impacted.
- Email addresses in Agent Workspace.最终用户的电子邮件地址将不会visible in Agent Workspace initially. This is also a limitation that we are actively working to remove. We would encourage businesses who wish to view the user’s email address in Agent Workspace to include this data in the JWT payload in order to prevent future development once this limitation is removed, but it is not necessary. Alternatively, you can use external id to surface email address, if the email address is a unique identifier for your customers.
121 Comments
Hi Justin,
This is likely to be an issue with your integration, as I don't believe we've any known issues of this nature on the Web Widget. Do you mind opening a Support ticket atsupport.zendesk.complease (Messaging icon in the lower right corner), and we'll assist you with this issue.
Hi Mick
Considering the console error I mentioned shows up even when there is nothing but the code I'm provided by Zendesk to install the messaging widget, and the console error is provided by Zendesk code, I completely disagree.
That said, I submitted a ticket. Hopefully, they can be more helpful. Thanks
Zendesk messaging I see doesn't have as many callbacks for us to use as the classic version does.
How do I know when the exp is about to expire and re-call the loginUser APi?
Using a timer to keep track and then calling loginUser is a bad solution
Hi Prakruti Hindia,
Has the new fix that you mentioned made it so that when the user sends a message from the widget and their external_id is set in the JWT, if there already existed a user with that same external_id then it wouldn't create a new one and instead asign that ticket to that "old" user?
Cheers,
Santiago
Hi Prakruti Hindia
When a user sends a widget message and its external_id is set by a JWT authentication, if there is already a user with the same external_id in the base (in the case of a base import, for example), will the application create a new user instead of linking it to the existing one?
So I've implemented the backend functionality to provide a signed JWT to the client part of the application, then I use the Web Widget API (https://developer.zendesk.com/documentation/zendesk-web-widget-sdks/sdks/web/sdk_api_reference/?_ga=2.111275911.280573301.1649945109-889103865.1649945109#authentication) to log the user in, after which in the response I can see that the JWT was successfully decoded. Yet, the `name` and `email` don't get pre-filled in the chat - should I somehow retrieve the users' Zendesk ID in our client application and add it to the JWT? I'd assume that this is the role of the Web Widget API... What might I be doing wrong there?
Hi Zendesk team,
I usingwidget classicand facing this issue when I called API:https://id.zopim.com/authenticated/web/jwtand I got this error: "error fetching shared secret"
I generatedSHARED_KEYinhttps://textback.zendesk.com/admin/account/security/end_users#messaging. Its right?
Did anyone solve the issue with not linking users?
We are also trying to create users via the APi with email and external_id and then identify them via a JWT token. But that just creates a new user without the external_id.
Pretty useless without this.
Danny Larsenwe haven't, and since then also moved on to a different solution.
For us being able to link users in live support use cases to our customer base is absolutely crucial. Neither this thread nor Zendesk Support had yet provided a satisfactory answer to even whether the fact Zendesk Messaging creates duplicate users with not even the external ID but also the sameemail addressis known behaviour, a bug of Zendesk, or should not happen and we were doing something wrong.
唯一的费用dback so far is that users will be "merged" as soon as the improvement goes live, with no further information on what this means in terms of data conflict resolution, etc.
这令人失望的是这样一个缺乏transparency for what probably comes down to the main use case of this feature for most people.
Hi Santiago, this will be rolled out in early May.
- Prakruti
Hi all,
Wanted to drop an update and provide more information on the upcoming fix (early May). Currently, the external id is surfaced on hover over the authentication badge. With the fix, the external id will be surfaced against theexternal id fieldin the user profile. If there is an existing user with the same external id as provided via API, the messaging ticket will reference the existing user.
We will be adding details on conflict resolution to this article once it is rolled out.
- Prakruti
Hello,Prakruti Hindia
Just wanted to inquire about `external_id` `JWT` issue.
Upcoming fix planned to early May - was it rolled out?
Or, when can we expect it?
HiPrakruti Hindia, has the external_id fix been postponed?
Cheers!
+1 on the above, any news? It is causing a very bad experience for our customers and we're getting complaints because we don't auto auth through the widget.
Hi everyone,
Apologies for the late response. I was hoping my next update would be a positive one. Unfortunately, it is taking longer than expected to roll out external id in user profile. I will update this thread in a few days with target rollout timeline.
Currently, external id is displayed on hover over the authenticated badge -https://support.zendesk.com/hc/en-us/articles/4411666638746/comments/4433112143130. (For new followers / readers of this post)
- Prakruti
https://support.zendesk.com/hc/en-us/community/posts/4640250446362-401-Unauthorized-Login-via-Messaging-SDK
Receiving 401 Unauthorised error when attempting \
Hi Ahmed,
Thanks for writing in! I've replied on the post that you have linked to.
HelloPrakruti Hindia,
Do you have a target rollout timeline for associating authenticated end users with already created end users via the external ID?
This is really a key feature, without it, authentication kind of seems pointless, as all Tickets created with authentication will not be properly linked to the end-user with contextual information etc.
Hello,
Prakruti Hindia, is there any update on the fix rollout time?
We ve prepared a feature within our App, that is blocked by the fix - we are waiting for it.
HiPrakruti Hindia
I'm joining all the previous inquiries on the date of the fix. I would appreciate knowing at least if this isn't something that's going to happen this month, so that we wouldn't wait in vain and move to another solution.
Thanks
Prakruti Hindia
It seems that the email is not carried over from the JWT to the created profile when Messaging with authentication is enabled. The external_id does show, but the email is not added to contacts, AND it creates a duplicate user instead of using the user with the same email that already exists. See ticket ID #10490436
Hi folks,
Wanted to drop a general update for associating external id with user profile and connecting messaging conversations to users based on it. This is our top priority and we are working on it. It is taking longer than expected. We understand it is critical to your workflows. I will drop an update soon with our new timelines.
- Prakruti
After implementing end-user authentication, we experience the same situation - the end-user email is not captured.
It is annoying as it is impossible to switch from messaging to email and have unread messages automatically emailed when the end-user leaves the messaging session.
To overcome this, we configured the external_id to have the email, and the agent must copy it when hovering over the authentication badge and then update it in the end-user profile.
What is the ETA for removing this limitation?
HelloPrakruti Hindia,
Could you please share us with updates if they are since latest news at June 15.
Hello,Prakruti Hindia
Could you please share any news about the issue and it's resolution?
It's already 3 weeks passed since latest updated.
We are blocked waiting for the fix.
Hi everyone,
Thank you for your patience. As I mentioned earlier, we have prioritised support for external id, which will associate external id with user profile and connecting messaging conversations to users based on it. We are targeting early Aug for the rollout. This will not include support for email. I will provide an update on email at later date.
- Prakruti
We're not even seeing the badge. Login is returning success with a correct externalId value on the swift object, but I don't see the badge in the dashboard anywhere.
Hello,Prakruti Hindia
Are thereany updates, timelines?
Please share some insights, so we were calm.
Even though the fix is really hot topic for us.
Why I didn't see any Messagin tab in Account > Security > End-user ?
Justin DoCanto- Did you ever figure out your issue? I'm having a very similar problem. Get an error unless I wrap the auth function in a try/catch and the auth itself isn't working. The function IS running though because I can hit the debugger if I put it right before the callback.
Pleasesign into leave a comment.