OAuth 2.0 Auth Code without Client Secret用于代替少数公司的客户端JavaScript应用程序的隐式授权。使用没有客户端秘密的Auth Code与隐式授权的一般优势/权衡是什么？是否有更多的公司和/或标准组织采用这种方式？
Red Hat，Deutsche Telekom和其他人已经按照这篇文章和IETF OAuth邮件列表的帖子进行了这样的发布。
隐式以前是为没有秘密的客户推荐的，但已经被授权代码授权所取代，并且没有任何机密。
...
以前，建议基于浏览器的应用程序使用“隐式”流程，该流程会立即返回访问令牌，并且没有令牌交换步骤。自规范最初编写以来，行业最佳实践已经改变，建议在没有客户机密的情况下使用授权代码流。这为创建安全流提供了更多机会，例如使用state参数。参考文献：Redhat，Deutsche Telekom，Smart Health IT。
以下是上面提到的消息。
对于我们的IDP [1]，我们的 javascript 库使用auth代码流，但需要公共客户端，redirect_uri验证，并且还进行CORS检查和处理。我们不喜欢Implicit Flow因为
1）访问令牌将在浏览器历史记录中
2）短期访问令牌（秒或分钟）需要浏览器重定向
德国电信也是如此。我们的 javascript 客户端也使用代码流与CORS处理，当然还有redirect_uri验证。
我们对SMART Health IT采取了类似的方法[1]，使用公共客户端的代码流来支持浏览器内应用程序，以及＆lt; 1h令牌生存期。 （我们还允许这些公共客户端通过请求“online_access”范围来请求有限持续时间的刷新令牌;这些刷新令牌在用户与AS的会话结束时停止工作 - 在会话概念有意义的系统中很有用。）< / p>
答案 0 :(得分：1)
2018年底，公共客户（SPA应用程序）的范例发生了很大变化。最初提出的隐式流程遭到了许多各方的批评。 2018年12月，发布了两个IETF草案，描述了可能的攻击媒介和最佳实践。两者都建议使用授权码流而不是隐式流。
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00
答案 1 :(得分：0)
答案在于此规范https://tools.ietf.org/html/rfc8252 它专门讨论用于本机应用程序的OAuth 2.0。第8.2 https://tools.ietf.org/html/rfc8252#section-8.2节解释了为何即使对于公共客户也不喜欢隐式流。 Microsoft Azure AD也已采用此方法。
“ OAuth 2.0隐式授予授权流程（在 OAuth 2.0 [RFC6749]的4.2节通常适用于这种做法 在浏览器中执行授权请求并接收 通过基于URI的应用间通信进行授权响应。 但是，由于隐式流不能被PKCE保护[RFC7636] （第8.1节中要求），将隐式流与 不推荐使用本机应用程序。
通过隐式流授予的访问令牌也无法刷新 无需用户交互，即可进行授权代码授予流程- 可以发出刷新令牌-更为实用的选择 需要刷新访问令牌的本地应用授权。”