[轉載]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。