使用没有客户端密钥的授权代码替换OAuth2隐式授权

Question

正在使用OAuth 2.0 Auth Code without Client Secret来代替少数公司的客户端JavaScript应用程序的隐式授权.使用没有客户端秘密的Auth Code与隐式授权的一般优势/权衡是什么？是否有更多的公司和/或标准组织采用这种方式？

Red Hat,Deutsche Telekom和其他人已经按照这篇文章和下面的IETF OAuth邮件列表发布了这种方式.

• https://aaronparecki.com/oauth-2-simplified/

之前建议客户使用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

我们对SMART Health IT [1]采用了类似的方法,使用公共客户端的代码流来支持浏览器内应用程序,以及<1h令牌生存期.(我们还允许这些公共客户端通过请求"online_access"范围来请求有限持续时间的刷新令牌;这些刷新令牌在用户与AS的会话结束时停止工作 - 在该会话概念有意义的系统中很有用.)

Answer 1

答案就在这个规范中https://www.rfc-editor.org/rfc/rfc8252 它专门讨论了本机应用程序的 OAuth 2.0。第 8.2 节https://www.rfc-editor.org/rfc/rfc8252#section-8.2解释了为什么即使对于公共客户端，隐式流也不是首选。微软Azure AD也走了这条路。

“OAuth 2.0 隐式授权流程（在 OAuth 2.0 [RFC6749] 的第 4.2 节中定义）通常适用于在浏览器中执行授权请求并通过基于 URI 的应用程序间通信接收授权响应的做法。但是，隐式流无法受到 PKCE [RFC7636] 的保护（第 8.1 节中要求），因此不建议在本机应用程序中使用隐式流。

通过隐式流授予的访问令牌在没有用户交互的情况下也无法刷新，这使得授权代码授予流（可以颁发刷新令牌）成为需要刷新访问令牌的本机应用程序授权的更实用的选择。”