Suite | Team, Growth, Professional, Enterprise, or Enterprise Plus |
已验证人工智能概要 ◀▼
对消息传送实施用户身份验证,确保对话连接到正确的终端用户,提高支持质量和安全性。将 JSON 网络密钥 (JWT) 与外部 ID 和可选电邮身份结合使用进行身份验证。管理员为开发者创建签名密钥以生成 JWT。配置电邮身份以提高安全性,并解决外部 ID 和电邮之间冲突,确保用户身份验证顺利进行。
提供对话支持时,用户可能会尝试在多个设备和渠道之间进行对话。对最终用户进行身份验证可确保所有联系点与正确的终端用户相关联。这样可以提高专员提供的客服质量,并提高专员协助终端用户时可能涉及的敏感信息的安全性。
相关文章:了解消息传送的用户身份验证。
消息传送身份验证的术语
- 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 条评论
Thomas
Es posible aplicar la identificacion por Whatsapp?
0
DMIT Admin
zE('messenger', 'loginUser', function (callback) {
callback(token);
})
I get 401 authentication error, and I want to know how to catch this error. I use try/catch for callback(token), but it's not work.
Thanks
0
DMIT Admin
Hi,
I need guidance on managing the login between the web login and the Zendesk end-user messaging login to keep them both synchronized.
Typically, I set the web session and JWT token to expire at the same time. However, there may be additional scenarios as follows:
0
Perry IT-RD
How does the web side pass JWT? Is there a corresponding API?
0
Javier DM
En relación a tu consulta, la opción de "Talk" en el widget está presente en el Web Widget (Classic), y no en la Mensajería, solo para aclarar ese punto.
Para tener una funcionalidad similar, deberían utilizar el API de Talk: Voice API in messaging quick start
Ahora en cuanto a la pregunta en la autenticación, y si estás utilizando WW (Classic), al momento de solicitar un callback aparecerá el formulario para completar y no puede modificarse. Por lo que la información la tomará de allí. Y si se trata de un cliente llamando, esto sería una llamada entrante en Talk, por lo que no habría una relación entre la autenticación del Widget y una llamada en la que se tiene visibilidad únicamente del número de teléfono.
Si tuvieras alguna consulta adicional sobre este tema, te sugiero crear una conversación con el bot en nuestro Centro de ayuda para crear un ticket de soporte y poder evaluar mas en detalle.
Un saludo y que tengas excelente comienzo de semana.
0
Agente2
Hola, buenas, me gustaria saber si existe la posibilidad de cuando se configure la autenticacion de usuario para el web widget esto permite que se autentiquen tamb para llamada y no solamente para mensajeria.
Ejemplo: tengo un web widget configurado con mensajeria, chat y llamadas, si el usuario se autentica en el web widget, esta autenticacion me funciona para identificar quien me llama por la linea digital que tengo configurada?.
Si no es asi, podrian darme algunas alternativas, ya sean aplicaciones de terceros o quizas alguna idea respecto a esto.
Gracias y espero su respuesta.
2
Darlene Pinto Costa
Does anyone have an example of authentication with nextjs?
Today the use is script, ex
<script
id='ze-snippet'
src='https://static.zdassets.com/ekr/snippet.js?key=123456'
/>
0
Chris Batt
The last paragraph doesn't match what we're seeing in production, and seems to contradict itself:
So we expect that if we send the `external_id` and `email` in the JWT, and the `external_id` is not matched to a user, but the `email` is matched to a user, that user is authenticated. However, we observe some vastly different outcomes depending on whether we're testing in Sandbox vs. Prod, or whether the user has a verified or unverified email address, or whether we include `email_verified` in the JWT, but there is no scenario we've seen where a user is authenticated as an existing user when the `email` matches and when the `external_id` doesn't. We see instead, a new user is created, or the login request fails. The latter outcome seems to agree with the next sentence following the one above:
Which is essentially saying “if the external_ids don't match, but the emails do, we authenticate the user, except if the external ids don't match”. So my question would be under what circumstances exactly would the `email` be used to authenticate the user as a fallback when the external ids don't match?
* this was not the case in sandbox testing, where we never saw logins fail, and a new user was created each time, which was seriously confusing why sandbox would behave different than prod. The results were also different in that depending on the user's email verification status, the newly created user would inherit the email, and multiple results would be returned from the API search endpoint when querying on the email. This all made testing and implementation incredibly difficult.
4
Jakub
A autenticação do Centro de Ajuda e a autenticação do widget são dois fluxos diferentes.
Como não há outra maneira nativa de fazer isso no momento, o processo de autenticação JWT ainda precisa ser implementado como seria para qualquer site externo.
0
Mayara Sousa
Boa tarde.
Porquê o BOT não consegue identificar o usuário logado no GUIDE Zendesk e criar o ticket associado ao email desse usuário ?
1
登录 to leave a comment.