最近搜索


没有最近搜索

Caroline Kello's Avatar

Caroline Kello

已加入2021年4月14日

·

最后活动2025年2月10日

Zendesk Product Manager

关注

0

关注者

2

活动总数

243

投票

32

订阅

96

活动概览

的最新活动 Caroline Kello

Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)

It's covered in this FAQ: 24 hours.

查看评论 · 已于 2025年1月29日 发布 · Caroline Kello

0

关注者

1

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)

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

查看评论 · 已于 2025年1月29日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)
Hey Molly, thank you for taking the time to provide us with this feedback! 
 
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.

查看评论 · 已于 2025年1月23日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)

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. 
 

查看评论 · 已于 2025年1月21日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)
Hey everyone, thanks for taking the time to provide us with this feedback! 
 
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.

查看评论 · 已于 2025年1月13日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Admin Center

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. 

查看评论 · 已于 2025年1月10日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

评论Single sign-on

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. 

查看评论 · 已于 2024年12月13日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 进行了评论,

评论Single sign-on

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. 

查看评论 · 已于 2024年11月06日 发布 · Caroline Kello

0

关注者

0

投票

0

评论


Caroline Kello 创建了一篇文章,

文章开发者更新
宣布日期 开始推行 结束推行
2024 年 8 月 27 日 2024 年 8 月 27 日 2025 年 2 月 17 日

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

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

此公告包括以下主题: 

有什么变化?

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_uristate(如果没有)。如果使用的是公开客户端,请务必包含 code_challengecode_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 客户支持

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

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

已于 2024年11月05日 编辑 · Caroline Kello

0

关注者

1

投票

0

评论


Caroline Kello 进行了评论,

社区评论 Feedback - Ticketing system (Support)

Is it the “New device added" email that you'd like to turn off? I'd love to know more about why that email isn't valuable to you. 

查看评论 · 已于 2024年10月15日 发布 · Caroline Kello

0

关注者

0

投票

0

评论