使用无客户端密码的授权代码替换 OAuth2 隐式授权 [英] Replacing OAuth2 Implicit Grant with Authorization Code without Client Secret
问题描述
一些公司正在使用 OAuth 2.0 Auth Code without Client Secret 来代替隐式授权，用于客户端 JavaScript 应用程序.使用无客户端机密与隐式授权的身份验证代码的一般优势/权衡是什么?是否有更多公司和/或标准组织采用这种方式?
OAuth 2.0 Auth Code without Client Secret is being used in lieu of Implicit Grant for client-side JavaScript apps by a few companies. What are the general advantages / tradeoffs of using Auth Code without Client Secret vs. Implicit Grant? Are there more companies and/or standards organizations moving this way?
Red Hat、Deutsche Telekom 和其他公司根据这篇文章和下面的 IETF OAuth 邮件列表帖子采取了这种方式.
Red Hat, Deutsche Telekom and others have moved this way per this article and the IETF OAuth mailing list posts below.
Implicit 以前推荐给没有秘密的客户端，但已被使用无秘密授权代码授权取代.
Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
...
以前，建议基于浏览器的应用程序使用隐式"流程，该流程立即返回访问令牌并且没有令牌交换步骤.自规范最初编写以来，行业最佳实践已更改为建议在没有客户端机密的情况下使用授权代码流.这为创建安全流提供了更多机会，例如使用状态参数.参考资料:Redhat、德国电信，智能健康 IT.
Previously, it was recommended that browser-based apps use the "Implicit" flow, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter. References: Redhat, Deutsche Telekom, Smart Health IT.
这是上面引用的消息.
对于我们的 IDP [1]，我们的 javascript 库使用身份验证代码流，但需要公共客户端、redirect_uri 验证，并且还进行 CORS 检查和处理.我们不喜欢隐式流，因为
For our IDP [1], our javascript library uses the auth code flow, but requires a public client, redirect_uri validation, and also does CORS checks and processing. We did not like Implicit Flow because
1) 访问令牌将在浏览器历史记录中
1) access tokens would be in the browser history
2) 短期访问令牌(秒或分钟)需要浏览器重定向
2) short lived access tokens (seconds or minutes) would require a browser redirect
德国电信也是如此.我们的 javascript 客户端也使用代码流和 CORS 处理，当然还有 redirect_uri 验证.
Same for Deutsche Telekom. Our javascript clients also use code flow with CORS processing and of course redirect_uri validation.
我们对 SMART Health IT [1] 采取了类似的方法，使用公共客户端的代码流来支持浏览器内应用，并且令牌生命周期小于 1 小时.(我们还允许这些公共客户端通过请求online_access"范围来请求有限持续时间的刷新令牌；当用户与 AS 的会话结束时，这些刷新令牌停止工作——在会话概念有意义的系统中很有用.)
We've taken a similar approach for SMART Health IT [1], using the code flow for public clients to support in-browser apps, and <1h token lifetime. (We also allow these public clients to request a limited-duration refresh token by asking for an "online_access" scope; these refresh tokens stop working when the user's session with the AS ends — useful in systems where that session concept is meaningful.)
推荐答案
在 2018 年底，公共客户端(SPA 应用程序)的范式发生了很大变化.之前推荐的隐式流程受到了许多方面的批评，如原始问题.2018 年 12 月，发布了两份 IETF 草案，描述了可能的攻击媒介和最佳实践.两者都推荐使用授权代码流而不是隐式流.
There was a big change in paradigm regarding public clients (SPA applications) in late 2018. Previously recommended implicit flow was criticized by a number of parties as quoted in the original question. In December 2018 two IETF drafts were published describing the possible attack vectors and best practices. Both recommend using authorization code flow instead of implicit flow.
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11
https://tools.ietf.org/html/草稿ietf-oauth-browser-based-apps-00
这篇关于使用无客户端密码的授权代码替换 OAuth2 隐式授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
