This article is intended for Zendesk administrators. 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
如前所述在上面的部分中,Zendesk管理亚博istrator 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.The email address of the end user will not be 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, I would like to consult asJorge Paezin what time frame you plan to implement the authentication to view the articles of the Zendesk Guide?
I would need this functionality so that my customers can see the documentation generated in the Guide about the use of my software.
I look forward to hearing from you!
Regards
HiCarlton
I went ahead & created a ticket on your behalf to look into what is happening with the badge. Please keep an eye out for our email so we can look into this further for you!
Hi,Prakruti Hindia
Are there any updates?
Hi everyone,
External id is now available in user profile for authenticated end-users. This improvement was rolled out in the week of Aug 23. I wanted to ensure that everyone following this discussion received the update.
Thank you all for your patience. If your team is unable to view external id and you have raised a support ticket, we will help you resolve it.
- Prakruti
Unfortunately, all the limitations here make it so that we cannot enable Messaging. The name and email is not carried over when the ticket is created, and private guide articles are not referenced when a customer is authenticated to the widget.
Such a downer
HiAimee Spanier, I noticed that the diagram in the Overview now includes Mobile SDK.
Previously the Mobile SDK has a different JWT flow where Zendesk will request the JWT token from our back-end.
1. Based on the updated flow, does it mean now the Mobile SDK also has the same JWT flow as messaging?
2. Is the primary key also using external_id ?
3. If I submit a request via Mobile SDK, and also trigger a request via messaging, will both requests be tagged to the same user profile?
HiPrakruti Hindia
Thanks for the updates. I have a few questions:
With a single external_id per Zendesk user, and a unique user id externally per brand, how does authentication succeed against the same end user?
Hi,
In my sandbox environment, I am able to login using JWT and able to obverse the user profile has the name and external_id that I set in the JWT token.
But in the production environment, I am not able to see it. From the logs, there are no error. Is there a way to check the Zendesk logs if the API is called successfully? I have engaged the support but the forum or blog.
If you have any additional questions, we recommend reaching out through the web and possibly by joining our developer community Forum (https://support.zendesk.com/hc/en-us/community/topics), Blog（https://developerblog.zendesk.com/) and/or Slack（https://docs.google.com/forms/d/e/1FAIpQLScm_rDLWwzWnq6PpYWFOR_PwMaSBcaFft-1pYornQtBGAaiJA/viewform) as this is the venue where you can reach out directly to our developers.
Prakruti Hindia
Issue is still there.
Users are not mapped correctly (a newduplicateuser gets created once initiated Messaging session).
It's very sad. So much time we were waiting for the fix.
Guys, do anybody can claim opposite - that issue had been fixed?
I can confirm that the messaging authentication is working as designed and conversations from users who have existing end-user profiles are being merged into that profile with the corresponding external ID in our Zendesk environment.
弗朗西斯,支持电子邮件在roadma签署p. Are you referring to carrying over private guide articles to the tickets ?
Yes, this is intended behavior.
Previous data - users and tickets will not be affected, if you decide to disable authentication.
We do not support this.
Ong Chin Shin and Zakhar, can you please raise a ticket with us ? We will look into it.
- Prakruti
Hi Zendesk team
web widget - login jwt payload was sent along with the email value, but we found an issue where the value was not saved.
Is the email value of null intentional? Or is it a bug?
step to reproduce
{ scope: 'user', role: "end-user", external_id: userEmail, email: userEmail, name: userName };https://{{domain}}support.zendesk.com/api/v2/users
body:
email value is null
Prakruti Hindia
Are you able to provide any kind of timeline for support for signed email (which you mentioned is on the roadmap)? This becomes a much, much larger implementation for us without it.
For those who found alternatives, will you please share what you used instead of this? It appears the email issue isn't going to be resolved soon and I don't see the value in this if we lose the fallback email options and all of the connected ticket history.
同样,别人有问题他们的机器人re-initializing anytime the page is loaded, even after a conversation has been handed over to an agent? The history of the conversation remains present - but if you refresh the page, the bot re-starts from the beginning flow as if it's a brand new inquiry. This behavior is not present where we use the widget without authenticating users so I don't understand why it's happening when authenticating a user.
I opened a ticket but estimated response was 2 days so hoping someone else may have some insight.
Does anyone have authenticated users set up for messaging that can tell me if this is working now?
By working I mean, when a customer is authenticated in messaging/web widget with the bot and is then transferred to an agent, does that messaging ticket get linked to a user account in Zendesk and show the customer's email address/user account in the requester ticket field?
We would love to implement this, but I am unsure if the problems were resolved. We need those tickets to come in attached to a user or have a new user created, just like tickets from other channels. Thanks for your help! - Jen
HiJen C- it is not working for us. Authenticated users come in without a name or email address, although the authentication is working based on the end user not being asked to enter their name or email. We are having issues with the bot re-launching on page refresh even though the history is brought in and I believe it's linked to the behind-the-scenes merge that is happening and the end user not being identified as having already been handed over to an agent. Perhaps someone else has additional details - I have an open ticket with ZD but am waiting for a reply still.
The big lack of info of this article is how to use in the flow builder infos that we've loaded/got by authentification..
A placeholders reference (such as {{sf.requester.email}}) would be most welcome
To be able to say "Hi {{requester.first_name}} how can I help you" for instance.
Raphaël Péguet - Officers.frI wasn't even aware that we could do this within our workflows... that would open a lot of possibilities.
We're still waiting for the feature where an authenticated end-user's email address is displayed in the Zendesk chat UI.
HIPrakruti Hindia,
Is there any news on this bug? is your team working on it? there are already 82 comments of people blocked and we haven't heard from you in a while. It's been almost a year since we identified this issue.
Can we organize a meeting with our developers to help? please give us any deadlines, we choose Zendesk to use the Guides for only logged-in users and we still can't use it.
Thank you,
Sergio
Hi everyone,
Wanted to chime in on the discussions here.
For cases where email is the primary identifier, I suggest passing email as external id. If the system finds another user with the same external id , it will reference the same end-user. Currently, the email value is not passed along. It is expected to not be able to retrieve email user using the Users API.
Surfacing email provided as part of authentication API is on the roadmap and are targeting Q1 for the rollout.
- Prakruti
HiPrakruti Hindia,
Our primary identifier is not the email, it's our internal ID. We have tried to pass it on the external id and it doesn't work either. Any other work around?
Thank you,
Sergio
HiSergio,
Just to add our experience. We've been aiming to use Zendesk Messaging for a long time now. Initially the main blocker was the lack of authentication (and so there would have been no way for our agents to know who a customer was without asking them - a non starter).
Following the release of authentication support, the next issue was that the "external_id" wasn't surfaced by the API (like you describe, we are setting this to our internal id for a user).
The "external_id" that you supply as part of authentication is now surfaced from the Zendesk Support API on the user object as of mid August this year.
We already have an internal app/plugin that we have written for Zendesk Support which fetches user details, order history etc from our CRM and displays it to our agents. Now that the "external_id" is available, we can use that - and so our plugin displays the customer name and email address to our agents.
Creating a Zendesk Support app/plugin is perhaps not the workaround you are looking for but it's definitely a solution. There are other benefits in being able to surface any information/context you want to your agents all within Zendesk Support.
Our thoughts are that Zendesk Messaging has been very much a work in progress/draft since it was released, and prior to August this year pretty much unusable for anything real (unless you want a terrible customer experience).
It's now usable we think with the above caveat, but still not an out-of-the-box solution. The improvements are arriving slowly, this is definitely "the future". We've evaluated a lot of alternatives to Zendesk and they all seem to fall short in other ways (lack of native mobile SDKs, lack of support for particular channels etc) so I think Zendesk is the most comprehensive solution.
Hope this is helpful.
Thanks,
Daniel
Hi! We are using jwt sso for messaging to authenticate users who use our mobile app. Currently we have faced a problem with end users created with random names in tickets. In zendesk admin panel > Customers section new users are being created as for example Visitor 88802267, but in jwt we are sending user name and email that user has in our mobile application. Before using jwt sso users would enter their name and/or email (in ios) and ticket would be created with name user entered, and then we decided to enable sso to use same email and name as in our mobile application. JWT generate process works as follows:
1. User signs in in our app.
2. Application sends GET request to our api that we developed in our backend with following data in payload -> user's name and email
3. API generates jwt and responds
4. Mobile application (which is written in Flutter) calls ZendeskMessaging.login() and sends jwt that it got from api request as paramater for login() method
5. zendesk messaging page opens and user starts conversation
Here is the example jwt token that is generated: eyJhbGciOiJIUzI1NiIsImtpZCI6ImFwcF82Mzg5OTcxNjdlM2NiMzAxMDVjMWJiODIiLCJ0eXAiOiJKV1QifQ.eyJzY29wZSI6InVzZXIiLCJuYW1lIjoidGVzdCIsImVtYWlsIjoidGVzdEBtYWlsLmNvbSIsImV4dGVybmFsX2lkIjoiODNjODA5NzItMjNmNi00MGU2LWEzNGItOWU2MmViYzhjZDRjIiwianRpIjoiZjRhZjg4NjAtMzg0OS00OGQ1LWI0Y2YtZTZmMmU3ZjEyZmZiIiwiaWF0IjoxNjcwMDY5MDI0fQ.HISo3nXh_4Egr80ffxwLsDUBSlbYqi5sPkkhZWyBxdE
We didn't quiet understand what is login redirect url is and that's why we just respond with jwt itself. Is it because we are using jwt sso incorrectly?
We were trying to view tickets in salesforce and we did manage to view, but after enabling jwt sso, tickets stopped being viewed in salesforce. I guess it is because the problem with users being created as Visiter + some random numbers.
Could you please help with finding what is the problem?
Anyone else getting a random name (ex. Visitor 66340348) for the user even though a name is in the token? The name seems to be received on Zendesk's end since the chat has a message saying "Changed their display name to ...", but the name is not actually changed.
HiPrakruti Hindia,
Could you please confirm if the email address being passed through is on track to be completed in Q1?
I'm having the same issue Eric. No matter what I do everything comes across as Visitor and some numbers.
I also can't figure out how for new conversations to appear in a separate ticket from the same authenticated user. Marking as solved, closing the chat on the user side, waiting over 10 minutes doesn't make a difference, it always just re-opens the original already Solved ticket.
For those still having issues with the setup, I wrote down the best practices I use when deployingAuthenticated Messagingin this article:
https://internalnote.com/jwt-messaging/
It includes:
Feel free to take a look and give feedback were it could be improved!
Is there a roadmap when the current limitations will be resolved? Like email address mapping to existing user?
Pleasesign into leave a comment.