我不知道我是否只是有某种盲点或什么,但我已多次阅读OAuth 2规范并仔细阅读邮件列表档案,我还没有找到一个很好的解释为什么隐含格兰特已经开发出用于获得访问令牌的流程.与授权代码授予相比,似乎只是放弃了客户端身份验证,没有非常令人信服的理由.这是如何"针对使用脚本语言在浏览器中实现的客户端进行优化"(引用规范)？
两个流程都是相同的(来源:http://tools.ietf.org/html/draft-ietf-oauth-v2-22):
- 客户端通过将资源所有者的用户代理指向授权端点来启动流.
- 授权服务器对资源所有者进行身份验证(通过用户代理),并确定资源所有者是否授予或拒绝客户端的访问请求.
- 假设资源所有者授予访问权限,授权服务器使用先前提供的重定向URI(在请求中或在客户端注册期间)将用户代理重定向回客户端.
- 重定向URI包括授权代码(授权代码流)
- 重定向URI包括URI片段中的访问令牌(隐式流)
这是流量分裂的地方.在这两种情况下,此时重定向URI都是由客户端托管的某个端点:
- 在授权代码流中,当用户代理使用URI中的授权代码命中该端点时,该端点上的代码会将授权代码及其客户端凭据交换为访问令牌,然后可以根据需要使用该令牌.例如,它可以将其写入页面上的脚本可以访问的网页中.
- Implicit流完全跳过此客户端身份验证步骤,只是加载带有客户端脚本的网页.这里有一个可爱的技巧,URL片段可以防止访问令牌过多传递,但最终结果基本相同:客户端托管的站点提供一个页面,其中包含一些可以获取访问令牌的脚本.
因此我的问题是:通过跳过客户端身份验证步骤获得了什么？