正在使用OAuth 2.0 Auth Code without Client Secret来代替少数公司的客户端JavaScript应用程序的隐式授权.使用没有客户端秘密的Auth Code与隐式授权的一般优势/权衡是什么？是否有更多的公司和/或标准组织采用这种方式？
Red Hat,Deutsche Telekom和其他人已经按照这篇文章和下面的IETF OAuth邮件列表发布了这种方式.
之前建议客户使用Implicit,但没有保密,但已被使用授权代码授权所取代.
...
以前,建议基于浏览器的应用程序使用"隐式"流程,该流程会立即返回访问令牌,并且没有令牌交换步骤.自规范最初编写以来,行业最佳实践已经改变,建议在没有客户机密的情况下使用授权代码流.这为创建安全流提供了更多机会,例如使用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]采用了类似的方法,使用公共客户端的代码流来支持浏览器内应用程序,以及<1h令牌生存期.(我们还允许这些公共客户端通过请求"online_access"范围来请求有限持续时间的刷新令牌;这些刷新令牌在用户与AS的会话结束时停止工作 - 在该会话概念有意义的系统中很有用.)