Recent searches
No recent searches
![Caroline Kello's Avatar](https://support.zendesk.com/system/photos/7683316036250/Kello_Caroline_076-2024-04-16-Zendesk-3873.jpg)
Caroline Kello
Joined Apr 14, 2021
·
Last activity Feb 10, 2025
Following
0
Followers
2
Total activity
244
Votes
32
Subscriptions
96
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Caroline Kello
Caroline Kello created an article,
Announced on | Rollout on |
February 12, 2025 | February 12, 2025 |
Starting today, all customers can require two-factor authentication when end users sign in.
This announcement includes the following topics:
What's changing?
Admins can now require end users to use two-factor authentication when they sign in to help center. Before today, this was optional for end users to turn on for themselves.
When two-factor authentication is turned on, end users will be asked to enter a passcode after entering their password. Users can get the passcode from a two-factor authentication app installed on their mobile device. Users must install a two-factor authentication app (such as Google Authenticator, Authy, or Duo Mobile) on their mobile device to receive a passcode.
Why is Zendesk making this change?
Zendesk is making this change to better align with best security practices and industry standards. In today’s security climate, relying on a password as your only authentication method is not enough, and requiring two-factor authentication helps ensure that the credentials being used are connected to a valid user.
The ability to require two-factor authentication for end users ensures that all users adhere to the same security standards, resulting in enhanced protection against unauthorized access and a stronger overall security posture.
What do I need to do?
If you want to require two-factor authentication for all end users, go to Admin Center > Account > Security > Advanced > Authentication and select Require two-factor authentication (2FA) for end users. After this setting is turned on, end users will be required to set up two-factor authentication the next time they sign in. See Managing two-factor authentication for details.
Leave this setting turned off if you want end users to optionally set up two-factor authentication for their own use.
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.
Edited Feb 12, 2025 · Caroline Kello
0
Followers
1
Vote
0
Comments
Caroline Kello commented,
It's covered in this FAQ: 24 hours.
View comment · Posted Jan 29, 2025 · Caroline Kello
0
Followers
1
Vote
0
Comments
Caroline Kello commented,
Hey Murph Murphy,
This doesn't align with the expected behavior, and we're not able to recreate what you're seeing either. If you could please contact our Customer Support so that we can figure out what's going on here.
Thanks, Caroline
View comment · Posted Jan 29, 2025 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
This feature request has been accepted and is on our roadmap for the first half of this year. Per our Community Guidelines, we can provide general guidance for anticipated feature and functionality release dates, and any discussion of planning is always subject to change. To stay on top of product releases please visit our What’s New page in the Help Center. We are going to leave this post open for comment to allow others to provide their feedback and use cases.
Thank you again for your feedback and for being a valuable customer with Zendesk.
View comment · Posted Jan 23, 2025 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
Hey Sarah,
Thanks for the detailed feedback regarding our announcement to deprecate these flows, I appreciate you taking the time to reach out.
After careful consideration of the security implications and industry standards, we must maintain our decision to deprecate both the Implicit grant type and Password grant type. Here are the key points for the Implicit grant flow that guided our decision:
- Security risks: The Implicit grant flow, while historically utilized for browser-based applications, poses significant security risks. It is more susceptible to phishing attacks and the token has a potential of being exposed. This exposure increases the risk of token interception and replay attacks, potentially compromising user data or allowing unauthorized access.
- Alignment with industry standards and best practices: The OAuth 2.0 Security Best Current Practice document recommends against using the Implicit grant flow. Instead, it advocates for the Authorization code flow with Proof Key for Code Exchange (PKCE), which provides a significantly higher level of security for authorization processes in browser-based applications. This method protects the authorization process and minimizes risks associated with token exposure. Here’s our documentation on Using PKCE to make Zendesk OAuth access tokens more secure.
- Enhancing our OAuth implementation: We have already implemented support for the authorization code flow with PKCE, which enhances the security of the authorization process. Additionally, we will be adding support for the client credentials flow, further aligning our offerings with modern security standards and providing a more secure environment for all customers.
While we recognize that you trust your specific environment and have built it securely, the Implicit grant flow is nevertheless considered less secure. We believe that providing an opt-in option would still expose our customers to risks which we feel are not acceptable. While the migration to the Authorization code flow does require effort, we believe that the long-term security benefits to all our customers outweigh the initial challenge in migration.
Thank you again for taking the time to share your feedback. We appreciate you being a valuable Zendesk Community member and customer.
View comment · Posted Jan 21, 2025 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
This is a great feature request and I have added it to the backlog for future consideration. This means that we will think about adding it as a priority later in our planning cycle. We are going to leave this post open for comment to allow others to provide their feedback and use cases, however please note as is stated in our Community Guidelines that we can not commit to prioritizing any one piece of feedback we receive in the community.
Thank you again for your feedback.
View comment · Posted Jan 13, 2025 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
Hey Vinicius - I completely agree with you and we have plans to address this setting this year. Appreciate you taking the time to leave such detailed feedback.
View comment · Posted Jan 10, 2025 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
Hey James, I'm Caroline from the Product team 👋 I'm assuming you're referencing Microsoft SSO for end users in particular here? We currently don't have any plans to address this in 2025, but I've added your feedback to our internal tool to make sure that it's captured and tracked accordingly.
View comment · Posted Dec 13, 2024 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello commented,
Hey Holly, we announced the release on September 30 and finished on October 4 - you should be able to see it now but let me know if for some reason it's still not showing up for you.
View comment · Posted Nov 06, 2024 · Caroline Kello
0
Followers
0
Votes
0
Comments
Caroline Kello created an article,
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?
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 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
parameters 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 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.
Edited Nov 01, 2024 · Caroline Kello
0
Followers
3
Votes
0
Comments