Announcing the removal of OAuth 2.0 grant types for Support

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 the 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? 
• Why is Zendesk making this change?
• What do I need to do?

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 the implicit grant flow, you'll need to:

• Update your current call to the /oauth/authorizations/new endpoint to use response_type: code instead of response_type: token and include the redirect_uri and state params if not already present. If using a public client, be sure to include the code_challenge and code_challenge_method parameters as well. See Generating the code_challenge value for more information on how to generate a code_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 the code_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 or 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 the password grant flow, 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.