一些公司正在使用没有客户端密钥的OAuth 2.0授权代码来代替隐式授权，用于客户端JavaScript应用程序。使用授权代码而不是隐式授权有哪些一般优势/权衡？是否有更多公司和/或标准组织朝这个方向发展？
根据本文和下面的IETF OAuth邮件列表帖子，Red Hat，Deutsche Telekom等公司已经采取了这种方式。 以前建议没有密钥的客户使用“隐式”流程，但现在已经被使用不带客户端密钥的授权码授权取代了。
......
以前，建议基于浏览器的应用程序使用“隐式”流程，该流程立即返回访问令牌，并且没有令牌交换步骤。自规范起草之日起，行业最佳实践已经改变，建议使用授权码流程而不带客户端密钥。这提供了更多创建安全流程的机会，例如使用状态参数。参考资料：Redhat，Deutsche Telekom，Smart Health IT。
根据本文和下面的IETF OAuth邮件列表帖子，Red Hat，Deutsche Telekom等公司已经采取了这种方式。 以前建议没有密钥的客户使用“隐式”流程，但现在已经被使用不带客户端密钥的授权码授权取代了。
......
以前，建议基于浏览器的应用程序使用“隐式”流程，该流程立即返回访问令牌，并且没有令牌交换步骤。自规范起草之日起，行业最佳实践已经改变，建议使用授权码流程而不带客户端密钥。这提供了更多创建安全流程的机会，例如使用状态参数。参考资料：Redhat，Deutsche Telekom，Smart Health IT。
这里是上面提到的消息。
对于我们的IDP，我们的javascript库使用授权代码流，但需要公共客户端、redirect_uri验证，并且还进行CORS检查和处理。我们不喜欢隐式流，因为1）访问令牌将在浏览器历史记录中，2）短暂的访问令牌（几秒或几分钟）需要浏览器重定向。 德国电信 同样适用于德国电信。我们的javascript客户端也使用带有CORS处理和重定向URI验证的代码流。 SMART Health IT 我们采取了类似的方法来支持基于浏览器的应用程序，使用公共客户端的代码流，以及小于1小时的令牌生存期。 （我们还允许这些公共客户端通过请求“online_access”范围来请求有限期的刷新令牌；当用户与AS的会话结束时，这些刷新令牌将停止工作-在具有该会话概念的系统中非常有用。）