一些公司正在使用不带客户端密钥的 OAuth 2.0 身份验证代码来代替客户端 JavaScript 应用程序的隐式授予。使用没有客户端密钥的身份验证代码与隐式授予的一般优点/权衡是什么？是否有更多的公司和/或标准组织正在这样做？
Red Hat、Deutsche Telekom 和其他公司已根据本文和下面的 IETF OAuth 邮件列表帖子采取了这种方式。
- https://aaronparecki.com/oauth-2-simplified/ https://aaronparecki.com/oauth-2-simplified/
Implicit以前推荐给没有秘密的客户，但已被使用没有秘密的授权代码授予所取代。
...
以前，建议基于浏览器的应用程序使用“隐式”流程，该流程立即返回访问令牌并且没有令牌交换步骤。自最初编写规范以来，行业最佳实践已发生变化，建议在没有客户端密钥的情况下使用授权代码流。这提供了更多创建安全流的机会，例如使用状态参数。参考：Redhat https://www.ietf.org/mail-archive/web/oauth/current/msg16966.html, 德国电信 https://www.ietf.org/mail-archive/web/oauth/current/msg16968.html, 智慧健康IT https://www.ietf.org/mail-archive/web/oauth/current/msg16967.html.
以下是上面引用的消息。
Red Hat https://www.ietf.org/mail-archive/web/oauth/current/msg16966.html
对于我们的 IDP [1]，我们的javascript库使用身份验证代码流，但需要公共客户端、redirect_uri 验证，并且还执行 CORS 检查和处理。我们不喜欢隐式流程，因为
1）访问令牌将在浏览器历史记录中
2) 短期访问令牌（秒或分钟）需要浏览器重定向
德国电信 https://www.ietf.org/mail-archive/web/oauth/current/msg16968.html
德国电信也是如此。我们的javascript客户端还使用带有 CORS 处理的代码流，当然还有 redirect_uri 验证。
智能健康信息技术 https://www.ietf.org/mail-archive/web/oauth/current/msg16967.html
我们对 SMART Health IT [1] 采用了类似的方法，使用公共客户端的代码流来支持浏览器内应用程序和
2018 年底，公共客户（SPA 应用）的范式发生了巨大变化。正如原始问题中所引用的那样，之前推荐的隐式流量受到了多方的批评。 2018 年 12 月发布了两份 IETF 草案，描述了可能的攻击媒介和最佳实践。两者都建议使用授权代码流而不是隐式流。
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-00
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
