Announced on | Rollout starts | Rollout ends |
August 27, 2024 | August 27, 2024 | February 17, 2025 |
In alignment with OAuth 2.0 best practices, Zendesk will stop accepting Implicit and Password grants for access tokens starting February 17, 2025, for Zendesk Support only. This removal does not apply to Chat, Sell, or Sunshine.
Customers are advised to switch to Authorization Code Flow or API tokens as soon as possible due to the insecurity of the older grant types.
This announcement includes the following topics:
What is changing?
On February 17, 2025, Zendesk will stop accepting the use of Implicit grant and Password grant as valid grant types for obtaining an access token. Customers will either need to migrate to the Authorization Code Flow grant type or API tokens. Starting today, anyone wanting to use OAuth 2.0 for authenticating API calls can only use the Authorization Code Flow grant type.
Why is Zendesk making this change?
In line with OAuth 2.0 best practices, the Implicit grant and the Resource Owner Password Credentials (Password) grant are now considered insecure and disallowed by the OAuth 2.0 Security Best Current Practice.
The Implicit grant used to be recommended because it directly returned the access token without needing an extra authorization code step. This was required for Public OAuth clients that could not securely store the client_secret. This method is now discouraged due to security risks, as it sends access tokens via HTTP redirects without client confirmation. It has been replaced with the more secure Authorization Code Grant with Proof Key for Code Exchange (PKCE). The Password grant is an outdated method for obtaining an access token by using a user's credentials. This method is now discouraged because it requires the client application to handle the user's password and send it to the authorization server, which results in an increased attack surface. It is also not compatible with two-factor authentication.
What do I need to do?
If you’re currently using Implicit grant, you will need to:
- Update your current call to the
/oauth/authorizations/new
endpoint to useresponse_type: code
instead ofresponse_type: token
and include theredirect_uri
andstate
params if not already present. If using a Public client, be sure to include thecode_challenge
andcode_challenge_method
params as well. See Generating the code_challenge value for more information on how to generate acode_challenge
. - Update or implement a new callback endpoint in your OAuth client. See Authorization Code grant implementation details in Using OAuth authentication with your application and Using PKCE to make Zendesk OAuth access tokens more secure for more information. For public clients, or if including a
code_challenge
in the/oauth/authorizations/new
call, be sure to include thecode_verifier
when calling the/oauth/tokens
endpoint. - Update your client at
/admin/apps-integrations/apis/zendesk-api/oauth_clients
in Admin Center to include your new/updated Redirect URI if it is not already present. - Once tested and validated, we encourage you to update the Client Kind at
/admin/apps-integrations/apis/zendesk-api/oauth_clients
in Admin Center to either public or confidential so that we can provide you with the highest level of security.
If you’re currently using Password grant, you have to use an API token instead.
If you have feedback or questions related to this announcement, visit our community forum where we collect and manage customer product feedback. For general assistance with your Zendesk products, contact Zendesk Customer Support.