Suite | 任意服务模式 |
提供对话支持时,用户可能会尝试在多个设备和渠道之间进行对话。对最终用户进行身份验证可确保所有联系点与正确的终端用户相关联。这样可以提高专员提供的客服质量,并提高专员协助终端用户时可能涉及的敏感信息的安全性。
相关文章:了解消息传送的用户身份验证。
消息传送身份验证的术语
- JWT:Zendesk 使用经过签名的 JSON 网络密钥 (JWT) 对消息传送的终端用户进行身份验证。这些密钥包含用于验证终端用户身份的详细信息。有关 JWT 的更多信息,请访问 jwt.io。
- 签名密钥:签名密钥由 Zendesk 管理员在管理中心创建,然后分享给您团队中的开发者,后者再根据需要使用它对 JWT 进行签名。
- 外部 ID:每个用户独有的字母数字字符串,例如来自外部系统的 ID。这是消息传送身份验证的主要标识,即使 JWT 中包含电邮地址时也是如此。
- 用户名:(可选)与外部 ID 或电邮地址关联的终端用户的名称。如果您在 JWT 中包含用户的名称,该名称将显示在专员工作区中。此信息可帮助专员与终端用户进行沟通。
- 电邮:(可选)与终端用户关联的唯一电邮地址。
对消息传送终端用户进行身份验证概述
Zendesk 使用 JSON 网络密钥 (JWT) 对消息传送终端用户进行身份验证,让您可以灵活、无状态的方式验证用户身份和保护 API 端点。
- 要进行消息传送身份验证,首先要由管理员生成签名密钥,并将其提供给开发者。然后,开发者使用签名密钥来实施后端服务,根据请求为用户创建经过签名的 JWT。
- 后端服务会应要求创建经过签名的 JWT,并将其返回到您的网站或移动应用。此服务创建的 JWT 必须包含唯一的外部 ID,也可以选择包含一个电邮地址,以识别终端用户的身份。
- 只要用户登录,您的网站或应用就需要调用适用于 Web Widget 和移动 SDK 的等效登录 API,此时 JWT 将被传递给 Zendesk 以验证用户所称身份。
有关更多信息(尤其对您团队中的开发者而言),请参阅使用 Zendesk SDK 允许通过身份验证的访客进行消息传送,或观看以下视频:
对网络消息传送的终端用户进行身份验证 (17:22)
创建并共享签名密钥
开发者使用签名密钥为终端用户创建 JWT。您必须是管理员才能创建签名密钥。您最多可以创建 10 个密钥。如果您在达到 10 个密钥的上限后尝试创建新密钥,系统会提示您删除未使用的密钥。
- 在管理中心,单击侧栏中的帐户 (
),然后选择安全 > 终端用户身份验证。
- 单击消息传送标签,然后单击创建密钥。
如果您是第一次创建密钥,页面底部会显示创建密钥。否则,它会显示在右上角。
- 输入密钥名称,然后单击下一步。
- 出现提示后,单击复制以复制共享密钥。
密钥已保存,且系统会自动分配一个 ID。您可以在终端用户身份验证页面的“消息传送”标签的密钥列表中找到密钥 ID。
- 将您复制的密钥 ID 和共享密钥以保密方式发送给开发者。
- 单击永久隐藏密钥。
仅使用外部 ID 对终端用户进行身份验证
要对终端用户进行身份验证,必须在颁发给用户的 JWT 中提供一个外部 ID。Zendesk 使用 JWT 中提供的外部 ID 作为消息传送用户身份验证的主要标识符。进行用户身份验证时,Zendesk 首先会使用外部 ID 解析现有用户。如果 JWT 中包含电邮地址,则仅当没有现有用户与外部 ID 匹配时,才会将其用于解析用户身份。
仅使用外部 ID 签署 JWT
- external_id:(必填)这是可用于识别每个用户的唯一字母数字字符串。请参阅选择要在颁发给用户的 JWT 中使用的外部 ID。
-
范围:(必填)来电人的访问范围。唯一有效的值是
user
。 - 名称:(可选)用户的名称。在 JWT 有效载荷中包含用户姓名可以在 Zendesk 专员工作区中显示用户姓名,帮助专员提供更多自定义支持。
{
"external_id": "12345678",
"scope": "user",
"name": "Jane Soap"
}
选择要在颁发给用户的 JWT 中使用的外部 ID
- 外部 ID 必须是字母数字字符串。
- 外部 ID 最多可以有 255 个字符。
- 在帐户级别,每个用户的外部 ID 必须是全局唯一的。
如果您的帐户有多个品牌,则外部 ID 在所有品牌中必须是唯一的。
- 不得更改用户的外部 ID。
- 每个用户只能有一个外部 ID。
外部 ID 有一些不错的选择,包括:首次联系时分配的递增或随机 ID(例如:usr_12345),或与分配的递增或随机 ID 相结合的品牌特定标识符(对于多个品牌,例如:brand1_a8ddg)。
避免使用用户的电邮地址和电话号码,因为这些信息会随时间变化,且用户可能有多个值。同时避免使用用户的名称,因为这可能不是唯一的。
将电邮身份整合到用户身份验证中
- 通过身份验证的用户通过签名 JWT 进行身份验证。
使用 JWT 提供了一种值得信赖的方法,因为签名 JWT 中的内容无法被终端用户篡改。如果您担心伪装攻击,则应仅限通过身份验证的终端用户使用电邮身份。这是最安全的选择,也是新 Zendesk 帐户的默认配置。
- 未经身份验证的用户是根据 Zendesk 智能机器人的提示提供电邮地址的终端用户。
请记住,允许未经身份验证的用户使用电邮身份会使您容易受到伪装攻击,因为他们可能会提供别人的电邮地址,冒充其他用户。
以下流程图演示了如何使用电邮身份进行消息传送身份验证:
配置电邮身份
通过 Web Widget 或移动应用,用户可以提供其电邮地址来回复表格或人工智能专员提示。在这种情况下,无法防止恶意用户提供他人的电邮地址来冒充他人。但是,使用 JWT 可通过外部 ID 和电邮身份对用户进行身份验证,让您可以一种更值得信赖的方式向用户分配电邮地址。
根据您的设置,专员可在用户个人资料中看到表格收集的和 JWT 提供的电邮地址。在新的 Zendesk 帐户中,电邮身份已开启并配置为仅使用已验证的电邮地址。这是最安全的选项。较早的帐户配置为使用已验证和未验证的电邮地址。
- 在管理中心,单击侧栏中的渠道 (
),然后选择消息传送和社交媒体 > 消息传送。
- 单击管理设置。
- 单击电邮身份,然后选择以下任一选项:
- 仅使用已验证的电邮地址:(默认)电邮身份只能为已通过身份验证且颁发给其的 JWT 中包含已验证电邮地址的用户创建。
- 使用已验证和未验证的电邮地址:除通过身份和电邮地址验证的用户的电邮身份外,用户通过人工智能专员工作流程提供的未验证电邮地址也会添加到用户个人资料中。
- (不推荐)如果您希望任何用户(包括未经身份验证的用户)能够认领已验证的电邮地址,请选择未经身份验证的用户可认领已验证的电邮地址。
- 单击保存设置。
仅使用已验证的电邮地址
电邮身份只能为通过身份验证且其颁发的 JWT 中包含已验证电邮地址的用户创建。
选择此选项后,专员会在对话记录中看到由未经身份验证的终端用户提供的电邮地址,但不会看到该用户的附加电邮身份。如果专员需要通过电邮跟进未经身份验证的用户,则必须手动在该用户记录中添加电邮身份。
使用已验证和未验证的电邮地址
除通过身份和电邮地址验证的用户的电邮身份外,用户通过人工智能专员工作流程提供的未验证电邮地址也会添加到用户个人资料中。
此选项的安全性较低,因为恶意用户仍可能尝试模拟攻击。但是,专员可以检查用户个人资料以确定电邮地址是否已验证。未验证的电邮地址会在专员工作区中清晰标记。当专员需要发送电邮进行跟进时,可以指示他们使用安全问题验证终端用户,以提高终端用户所称身份的置信度。
活动顺序 | 活动 | 生成电邮身份 |
---|---|---|
1 | 未经身份验证的用户提供一个表格收集的电邮地址,例如 alice@example.org | Zendesk 使用未验证的电邮身份 (alice@example.org)创建一个新的未经身份验证的用户(id:12345)。 |
2 | 通过身份验证的用户收到一个 JWT,其中包含以下声明:
|
Zendesk 使用已验证的电邮身份 (alice@example.org)创建一个新的未经身份验证的用户(id:22345)。 未经身份验证的用户(id:12345) 将失去其未验证的电邮身份,因为后者已被已验证的身份取代。 |
允许未经身份验证的用户声明已验证的电邮地址(不推荐)
与其他电邮身份选项不同,使用此设置时,用户只需在出现提示时提供其电邮地址即可使用已通过身份验证的用户身份。选择后,已验证电邮不会取代未验证电邮。
此选项的安全性最差,最容易受到伪装攻击。但是,在这种情况下,专员只需查看用户个人资料上及其消息旁的绿色勾号图标(表明用户是否已通过身份验证)即可识别伪装者。
选择此选项后,从消息传送渠道收集的电邮身份验证状态将不再可信,因为用户通过身份验证后可能会出现伪装者,伪装者会在以后的消息传送交互中窃取用户的电邮状态。这意味着伪装攻击更容易得手,而专员也很难确认终端用户所声称的身份是否真实。但是,已验证的电邮身份仍会取代未验证的电邮身份,且该电邮身份将从伪装者的用户记录中移除。
使用电邮地址发布 JWT
- external_id:(必填)这是可用于识别每个用户的唯一字母数字字符串。请参阅选择要在颁发给用户的 JWT 中使用的外部 ID。
-
范围:(必填)来电人的访问范围。唯一有效的值是
user
。 - 名称:(可选)用户的名称。在 JWT 有效载荷中包含用户姓名可以在 Zendesk 专员工作区中显示用户姓名,帮助专员提供更多自定义支持。
-
电邮:(必填)登录用户的电邮地址。每个用户的电邮必须是唯一的。
在专员工作区中将电邮地址设置为用户的主要电邮地址。不支持在 JWT 中包含备用电邮地址。
-
email_verified:(可选)终端用户是否已证明对相关电邮地址的所有权。如果您希望终端用户具有已验证的电邮身份,则您发布的 JWT 必须同时包含
email
和"email_verified": true
。
{
"external_id": "12345678",
"email": "janes@soap.com",
"email_verified": true,
"name": "Jane Soap",
"scope": "user"
}
解决 JWT 中外部 ID 和电邮之间的冲突
Zendesk 使用外部 ID 作为主要标识符,仅在未找到与外部 ID 匹配的情况下使用电邮地址。
实施消息传送身份验证时,应尽量避免冲突。例如,在 Zendesk 中选取外部 ID 和电邮设置,以确保它们不会冲突。然而,如果 JWT 中显示的电邮地址已经与不同的外部 ID 关联,Zendesk 将拒绝 JWT,终端用户的登录尝试也会失败。在这种情况下,对话开始时用户处于未经身份验证的状态。
- 更新 JWT 以使用不同的
external_id
值或email
地址。或
- 删除
external_id
冲突的用户,腾出空间供其他终端用户使用。请参阅在 Sunshine Conversations API 中删除用户。
167 条评论
Ivan Genchev
Hello Everyone,
I would like to share our experience with authenticating users and the disappointment following.
We are supporting tens of brands and authenticating users who log in in our websites and open a chat (messaging) via the widget. Each of our brands has a unique set of numbers as External ID. Users can register in any of our brands with the same email and they will be generated a different External ID for each Brand. This information is provided to Zendesk and a user is created in Support.
Sounds simple enough, however, once a user registers in more than 1 of our brands, they are forbidden by Zendesk to initiate a chat in the 2nd, 3rd, or any other brand after the first registration. This is due to the 409 error. The “solution” in the article is to manually or via API, remove the original user so that they can be registered anew and open a chat in the new brand, but this does not help as this would need to happen each time the user tries to open a chat in the original brand or in a new one.
For some reason, Sunshine Conversations cannot comprehend the same Email, being related to more than one External ID (or, since the External ID is the main identifier, more than 1 External ID cannot be related to the same Email). Which could make sense in some cases, but not for a platform that offers Multi-Brand usage.
“Solution” 1: To not pass our external IDs as External_ID, but pass the email as an External_ID. In this case, no matter where the user registers/logins, we will pass the same External_ID to Zendesk and there will be no conflict. Sounds good, the first registration is successful. The second registration (to a 2nd Brand) is also successful. However, users can view the history of the first brand in the chat of the second brand. This is absolutely baffling. Why would this even be a feature, why would a user need the history of Brand1 in the chat of Brand2? This can be a huge breach of trust in the customer. The answer to this question is that Sunshine Conversations just works like that..
“Solution” 2: What we are currently doing: Authenticate users as usual, and create a fallback for when a user encounters the 409 error (registered in more than 1 brand and initiates a chat). The fallback authenticates the user with the External ID, however instead of using the same Email, it creates a new email for them which looks like this: External_ID+Email (ex. 123456789+example@email.com). This is made so that each new registration in another brand will have a different email, so that Zendesk can allow them to be registered anew, instead of blocking them.
- So now if 1 user, with the email example@email.com registers in 3 Brands, he will have 3 separate users in Zendesk:
One as example@email.com , Second as 123456789+example@email.com and Third as 987654321+example@email.com .
- Great, at least they can initiate chats now. The issue? Only the original user can be used for email communication, as he is the only one with an actually legit email. So any email sent from/to Brand2 and Brand3 will go to the user for Brand1. Any chat communication will be saved in the interaction history for the respective user, but emails will never be seen as they should.
- So if the user comes in Brand3 and says “check the email communication”, you cannot simply view the Interaction History, you have to open an entirely separate user and check the email communication there.
- Sometimes, the original email example@email.com and an email such as 123456789+example@email.com will be added to the same user. In many of these cases, the 123456789+example@email.com is marked as Primary in the user's Zendesk profile. For another unknown reason, Zendesk does not allow us to send emails to the Secondary email, and it is only used for identification. So even if you type out example@email.com in the “Requester field”, it will recognize the user and automatically change the Requester to the primary email 123456789+example@email.com . This is obviously a non-existent email, so the sending will fail.
The only solution to this is to go inside the profile of the user, mark the example@email.com as verified and then change it to primary. Only then can an agent send an email to this customer.
The other “Solution” would be to not authenticate users at all but you can imagine how that is not exactly a solution.
After thorough communication with Zendesk Support, it seems this is our only workaround which includes all these pain points that force agents to do unnecessary manual work.
To us this seems as a major flaw for a platform that support multiple brands and I believe a solution to this should be of highest priority. At this point, the platform is basically punishing the customer for having a registration in more than 1 brand with the same email, and any workaround feels unpolished and irritating to agents for the manual steps they need to take.
I look forward to any feedback or other possible solutions that you may offer.
Thank you.
2
Anthony Plaza
Hello everyone, specific question.
Was the email authentication issue resolved?
I send the email, external_id, and other information in my JWT, but I've read all the messages since 2022, and it's April 2025, and I'm not sure whether to add the "email_verified" field since they say it duplicates the number of users.
Please confirm if this new feature is working correctly.
0
John Witt
8329079355674 I have found that Zendesk requires an email_verified status to see non-public articles. I send the userid of the current user ($AJAX user.me) as the external_id, email_verified true, and the email to create the token. The problem with this is it will always create a new user since external_id doesn't exists, so one workaround is to prepopulate every user's external_id with their user_id before testing Messaging. I prefer make.com and powerautomate, but I assume any integration tool or ZIS could do it. Worst case is you have two users and need to merge.
0
Pierre
Thanks 1263169242090
Just to make sure I understand it correctly.
Can I pre-populate the external id in zendesk or do I need to do this using an API?
My assumption is that the bot can automatically recommend articles based on the questions the end user asks. Or do we still need to pre-configure recommended articles for certain questions within the bot?
Thanks again for your help.
0
John Witt
My articles were private, and the only way around this is to use email, external id, and email_verified=true. However, if you don't pre-populate the external id before doing this, it will create a new user (you'll need to merge or delete the other one).
0
Pierre
1263169242090, thanks for you response.
We did get he web widget to work by using the backend service. We use the JWT token as described, but still the bot does not return any useful articles. Only when we make our articles public it works as it should.
Is there a setting somewhere in Zendesk that will allow the bot to return articles without us having to make all our articles public facing?
0
John Witt
8329079355674 To properly encode, you need the algorithm of H256, the correct kid (from Account;end user security), and type of JWT. The payload really just needs scope=user and external_id, but I use email, name, and verified.
I recommend using one of the JWT encoder/decoders and hardcode the value into the ZE call until you get it working. You might be missing a parm to encode in your encoder. I found I was getting 401 Login issues as I was using the wrong kid to encode.
0
Pierre
Hi,
We have build our backend service that will generate the JWT tokens. We have followed the instructions as per the steps in this document.
We generate a JWT token with the required claims and then use the token in Postman as a Bearer token to test it. But we keep on receiving the status code 401.
Is there anything else we should have configured on Zendesk apart from the Signing key in the Messaging section?
Or should the issuer and audience properties of the JWT token be specific values?
0
John Witt
1265194314089 Did you ever get an answer to this? I am seeing the same. It's almost like I want to add more logic - get the user via email, and if they don't have an external id, then create one using their user id, then send the JWT request. I think the issue is it sees there' no external_id, but can't use the email since it's already in use, and doesn't just assume the one with the correct email address is correct.
0
Tamir Bashkin
Hey, check out this app: https://www.zendesk.com/marketplace/apps/support/1066145/messaging-and-help-center-authentication . It helps authenticate Help Center users on the messaging widget. Highly recommended! :)
0
登录再写评论。