宣布日期 开始推行 结束推行
2024 年 8 月 27 日 2024 年 8 月 27 日 2025 年 2 月 17 日

根据 OAuth 2.0 最佳实践,Zendesk 将从 2025 年 2 月 17 日起停止接受访问密钥的隐式访问和密码授予,仅限 Zendesk Support。此项移除不适用于 Chat、Sell 或 Sunshine。

由于较早的授权类型存在不安全性,建议客户尽快切换到授权代码流程或 API 密钥。

此公告包括以下主题: 

  • 有什么变化? 
  • Zendesk 为何作出这项更改?
  • 我需要做些什么?

有什么变化?

2025 年 2 月 17 日,Zendesk 将停止接受使用隐式授权和密码授权作为获取访问密钥的有效授权类型。客户将需要迁移到 授权代码工作流程 授予类型或 API 密钥。即日起,任何想要使用 OAuth 2.0 对 API 调用进行身份验证的人只能使用授权码工作流程授予类型。

Zendesk 为何作出这项更改?

根据 OAuth 2.0 最佳实践,隐式授予和资源所有者密码凭证(密码)授予现被视为不安全,被 OAuth 2.0 安全最佳实践所禁止。

过去之所以推荐使用隐式授权,是因为它直接返回访问密钥,无需额外的授权代码步骤。对于无法安全存储 client_secret的公开 OAuth 客户端,这是必需的。现在不推荐使用该方法,因为它不经过客户端确认通过 HTTP 重定向发送访问密钥,存在安全风险。它已被安全性更高的授权代码所取代,该授权代码授予带有代码交换证明密钥 (PKCE)。使用用户凭证获取访问密钥时,授予密码是一种过时的方法。现在也不推荐使用该方法,因为它需要客户端应用程序处理用户密码并将其发送到授权服务器,从而导致攻击面增加。此外,它还不兼容双重身份验证。

我需要做些什么?

如果您当前在使用隐式授权工作流程,则需要:

  • 更新当前 /oauth/authorizations/new 端点调用,以使用 response_type: code 而不是 response_type: token,并包含参数 redirect_uri 和 state(如果没有)。如果使用的是公开客户端,请务必包含 code_challenge 和 code_challenge_method 参数。请参阅生成 code_challenge 值,了解更多关于如何生成 code_challenge 的信息。
  • 在您的 OAuth 客户端中更新或实施新的回拨端点。有关更多信息,请参阅 对您的应用程序使用 OAuth 身份验证 和 使用 PKCE 提高 Zendesk OAuth 访问密钥 中的授权代码授予实施详情。对于公开客户端,或如果 /oauth/authorizations/new 调用包含 code_challenge,请务必在调用 /oauth/tokens 端点时包含 code_verifier。
  • 于 更新客户端 /admin/apps-integrations/apis/zendesk-api/oauth_clients 添加您新建或更新的重定向 URI(如果没有)。
  • 经过测试和验证后,建议在管理中心 (/admin/apps-integrations/apis/zendesk-api/oauth_clients) 更新客户端类型,将其设置为公开或保密,以便我们为您提供最高级别安全保护。

如果您当前使用的是密码授予工作流程,则必须使用 API 密钥。

如果您对此公告有任何反馈或疑问,请访问我们的社区论坛,我们将在这里收集和管理客户对产品的反馈。如需获取关于 Zendesk 产品的常规帮助,请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

由 Zendesk 提供技术支持