[转载]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。