[转载]OAuth、OAuth2与OpenID区别和联系

原文地址：OAuth、OAuth2与OpenID区别和联系 作者：杭州丁俊

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
        OAuth协议 为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAuth是 安全的。同时，任何第三方都可以使用OAuth认证服务，任何服务提供商都可以实现自身的OAuth认证服务，因而OAuth是 开放的。

OAuth简史：
2007年12月4日发布了OAuth Core 1.0， 此版本的协议存在严重的安全漏洞：OAuth Security Advisory: 2009.1，更详细的安全漏洞介绍可以参考：Explaining the OAuth Session Fixation Attack。
2009年6月24日发布了OAuth Core 1.0 Revision A：此版本的协议修复了前一版本的安全漏洞，并成为 RFC5849，我们现在使用的OAuth版本多半都是以此版本为基础。
OAuth 2.0是OAuth协议的下一版本，但 不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。

OAuth角色:

• Consumer：消费方
• Service Provider：服务提供者
• User：用户

OAuth流程：

• 用户访问客户端的网站，想操作用户存放在服务提供方的资源。
• 客户端访问服务提供方的临时令牌页面申请一个临时令牌。
• 服务提供方验证客户端的身份后，授予一个临时令牌。
• 客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
• 用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。
• 授权成功后，服务提供方引导用户返回客户端的网页。
• 客户端根据临时令牌访问服务提供方的访问令牌页面 获取访问令牌。
• 服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
• 客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

有腿的OAuth
        我们前面描述的OAuth，被称为 三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及前面提到的三种角色，也就是： 消费方，服务提供者，用户。不过有 些情况下，不需要用户的参与，此时就产生了一个变体，被称作 两条腿的OAuth（2-Legged OAuth），一般来说， 访问私有数据的应用需要三条腿的OAuth，访问公共数据的应用需要两条腿的OAuth。
         两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与， 所以在流程中就不会涉及用户授权的环节，也就不需要使用Token，而主要是 通 过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret 基本等价于账号和密码的作用。

OAuth和OpenID的区别：
OAuth关注的是 authorization授权，即：“用户能做什么”；
 而 OpenID侧重的是authentication认证，即：“用户是谁”。
OpenID、OAuth联合使用例子：

• OpenID 用户希望访问其在example.com的账户
• example.com(在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
• 用户给出了他的OpenID，比如说"http://user.myopenid.com"
• example.com 跳转到了用户的OpenID提供商“mypopenid.com”
• 用户在"myopenid.com"(OpenID provider)提示的界面上输入用户名密码登录
• “myopenid.com" (OpenID provider) 问用户是否要登录到example.com
• 用户同意后，"myopenid.com" (OpenID provider) 跳转回example.com
• example.com 允许用户访问其帐号
• 用户在使用example.com时希望从mycontacts.com导入他的联系人
• example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
• 用户在mycontacts.com 登录(可能也可能不用了他的OpenID)
• mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人
• 用户确定
• mycontacts.com 把用户送回example.com
• example.com 从mycontacts.com拿到联系人
• example.com 告诉用户导入成功

        上面的例子告诉我们， OpenID是用来认证协议，OAuth是授权协议，二者是互补的。OAuth来自Twitter，可以让A网站的用户共享B网站上的他自己的资源，而不需泄露用户名和密码给另外一个网站。OAuth可以把提供的Token，限制在一个网站特定时间段的的特定资源。

Google Connect(基于OpenID +  OAuth思想的定制)：


OAuth 2.0的新特性 - 6种全新流程:

• User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。
• Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。
• Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器
• Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。
• Client Credentials Flow – 客户端使用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。
• Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。

OAuth 2.0的新特性:
        持信人token - OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过 HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。
        签名简化 - 对于签名的支持，签名机制大大简化，不需要特殊的解析处理，编码，和对参数进行排序。 使用一个secret替代原先的两个secret。
        短期token和长效的身份凭据 - 原先的OAuth，会发行一个有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个 短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期。
        角色分开 - OAuth 2.0将分为两个角色： Authorization server负责获取用户的授权并且发布token； Resource负责处理API calls。

转载于:https://www.cnblogs.com/liuzhuqing/p/7480145.html