| 宣布日期 | 开始推行 | 结束推行 |
| 2025 年 4 月 30 日 | 2025 年 4 月 30 日 | 2025 年 5 月 30 日 |
即日起，客户可采用符合 OAuth 2.0 标准的 OAuth 刷新密钥授权类型，并支持访问和刷新密钥过期。第三方应用开发者（在市场中发布整合和应用的开发者）必须在 2026 年 1 月 31 日之前采用 OAuth refresh_token 工作流程。客户必须在 2026 年 4 月 30 日之前完成此操作。
此公告包括以下主题：
有什么变化？
Zendesk 推出了 OAuth 刷新密钥授权类型，作为采用 OAuth 访问密钥过期工作流程的第一阶段。该授权类型用于刷新已过期或即将过期的访问密钥。我们的团队现推出此工作流程供您采用。第三方应用开发者必须在 2026 年 1 月 31 日之前采用 OAuth 刷新工作流程。到 2026 年 4 月 30 日，所有客户都必须使用该工作流程。
要使用此工作流程，请使用 grant_type: refresh_token 传递有效的 refresh_token 参数到 /oauth/tokens 端点以生成新的 OAuth 访问密钥。请求成功后还将返回一个刷新密钥，并删除以前的访问密钥和刷新密钥。为了便于全面测试 refresh_token 流程和密钥过期时间，您也可以传递 expires_in 和 refresh_token_expires_in 参数到 /oauth/tokens 端点，同时使用 authorization_code 和 refresh_token 授权类型以设置访问密钥过期。如果您设置了过期时间，它将被应用和执行。
在第一阶段，即日起，系统将对所有新的 OAuth 密钥请求授权刷新密钥。现有 OAuth 密钥将无法刷新。现有应用程序和整合将继续照常工作。
Zendesk 为何作出这项更改？
通过此更新，我们能够进一步与 OAuth 2.0 标准保持一致，为客户和开发者提供更强大、更灵活的 API 身份验证。
我需要做些什么？
如果您使用 OAuth 对 API 请求进行身份验证，您的应用程序或整合必须采用 refresh_token 授权类型。有关更多信息，请参阅对您的应用程序使用 OAuth 身份验证。
如果您对此公告有任何反馈或疑问，请访问我们的社区论坛，我们将在这里收集和管理客户对产品的反馈。如需获取关于 Zendesk 产品的常规帮助，请联系 Zendesk 客户支持。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。