OAuth 2 中隐式授予授权类型的目的是什么? [英] What is the purpose of the implicit grant authorization type in OAuth 2?
问题描述
我不知道我是否只是有某种盲点或什么，但我已经多次阅读 OAuth 2 规范并仔细阅读邮件列表档案，但我还没有找到一个很好的解释为什么已开发用于获取访问令牌的隐式授予流程.与 Authorization Code Grant 相比，它似乎只是为了没有非常令人信服的理由而放弃客户端身份验证.这如何针对使用脚本语言在浏览器中实现的客户端进行优化"(引用规范)?
I don't know if I just have some kind of blind spot or what, but I've read the OAuth 2 spec many times over and perused the mailing list archives, and I have yet to find a good explanation of why the Implicit Grant flow for obtaining access tokens has been developed. Compared to the Authorization Code Grant, it seems to just give up on client authentication for no very compelling reason. How is this "optimized for clients implemented in a browser using a scripting language" (to quote the specification)?
两个流程开始时相同(来源:http://tools.ietf.org/html/draft-ietf-oauth-v2-22):
Both flows start out the same (source: http://tools.ietf.org/html/draft-ietf-oauth-v2-22):
- 客户端通过将资源所有者的用户代理定向到授权端点来启动流程.
- 授权服务器对资源所有者进行身份验证(通过用户代理)，并确定资源所有者是授予还是拒绝客户端的访问请求.
- 假设资源所有者授予访问权限，授权服务器使用之前提供的重定向 URI(在请求中或客户端注册期间)将用户代理重定向回客户端.
- 重定向 URI 包含授权代码(授权代码流)
- 重定向 URI 在 URI 片段中包含访问令牌(隐式流)
这里是流量分流的地方.在这两种情况下，此时的重定向 URI 都指向客户端托管的某个端点:
Here's where the flows split. In both cases the redirection URI at this point is to some endpoint hosted by the client:
- 在授权代码流中，当用户代理使用 URI 中的授权代码访问该端点时，该端点的代码会交换授权代码及其客户端凭据以获取访问令牌，然后可以根据需要使用该令牌.例如，它可以将其写入网页上的脚本可以访问的网页.
- 隐式流程完全跳过此客户端身份验证步骤，只加载带有客户端脚本的网页.URL 片段有一个可爱的技巧，可以防止访问令牌传递过多，但最终结果基本相同:客户端托管的站点提供一个页面，其中包含一些可以获取访问令牌的脚本.
因此我的问题是:跳过客户端身份验证步骤有什么收获?
Hence my question: what has been gained here by skipping the client authentication step?
推荐答案
以下是我的想法:
在授权代码流中使用 auth code + token 的目的是令牌和客户端机密永远不会暴露给资源所有者，因为它们在服务器到服务器之间传输.
The purpose of auth code + token in authorization code flow is that token and client secret will never be exposed to resource owner because they travel server-to-server.
另一方面，隐式授权流程适用于完全使用 JavaScript 实现并在资源所有者的浏览器中运行的客户端.您不需要任何服务器端代码即可使用此流程.然后，如果所有事情都发生在资源所有者的浏览器中，那么发出验证码 & 就没有意义了.客户端秘密了，因为令牌 &客户端机密仍将与资源所有者共享.包括授权码 &客户端密钥只会使流程更加复杂，而不会增加任何真正的安全性.
On the other side, implicit grant flow is for clients that are implemented entirely using javascript and are running in resource owner's browser. You do not need any server side code to use this flow. Then, if everything happens in resource owner's browser it makes no sense to issue auth code & client secret anymore, because token & client secret will still be shared with resource owner. Including auth code & client secret just makes the flow more complex without adding any more real security.
那么答案是得到了什么?"是简单".
So the answer on "what has been gained?" is "simplicity".
这篇关于OAuth 2 中隐式授予授权类型的目的是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
