相关疑难解决方法(0)

我不知道我是否只是有某种盲点或什么,但我已多次阅读OAuth 2规范并仔细阅读邮件列表档案,我还没有找到一个很好的解释为什么隐含格兰特已经开发出用于获得访问令牌的流程.与授权代码授予相比,似乎只是放弃了客户端身份验证,没有非常令人信服的理由.这是如何"针对使用脚本语言在浏览器中实现的客户端进行优化"(引用规范)？

两个流程都是相同的(来源:http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

1. 客户端通过将资源所有者的用户代理指向授权端点来启动流.
2. 授权服务器对资源所有者进行身份验证(通过用户代理),并确定资源所有者是否授予或拒绝客户端的访问请求.
3. 假设资源所有者授予访问权限,授权服务器使用先前提供的重定向URI(在请求中或在客户端注册期间)将用户代理重定向回客户端.
   • 重定向URI包括授权代码(授权代码流)
   • 重定向URI包括URI片段中的访问令牌(隐式流)

这是流量分裂的地方.在这两种情况下,此时重定向URI都是由客户端托管的某个端点:

• 在授权代码流中,当用户代理使用URI中的授权代码命中该端点时,该端点上的代码会将授权代码及其客户端凭据交换为访问令牌,然后可以根据需要使用该令牌.例如,它可以将其写入页面上的脚本可以访问的网页中.
• Implicit流完全跳过此客户端身份验证步骤,只是加载带有客户端脚本的网页.这里有一个可爱的技巧,URL片段可以防止访问令牌过多传递,但最终结果基本相同:客户端托管的站点提供一个页面,其中包含一些可以获取访问令牌的脚本.
  

因此我的问题是:通过跳过客户端身份验证步骤获得了什么？

Facebook文档:

Facebook平台支持两种不同的OAuth 2.0流程供用户登录:服务器端(在规范中称为身份验证代码流)和客户端(称为隐式流).只要您需要从Web服务器调用Graph API,就会使用服务器端流程.当您需要从客户端调用Graph API时,使用客户端流,例如在Web浏览器中运行的JavaScript或从本机移动或桌面应用程序.

这些流程访问令牌之间有什么区别？似乎它们的长度不同.

我们可以在客户端上使用服务器端流程令牌吗？否则,我们可以在服务器上使用客户端流令牌吗？