OAuth和OpenID的區別(轉)

時間 2019-12-10

標籤 oauth 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。參考： OAuth2.0 OpenID&Oauth The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-31 安全聲明（斷言）標記語言 saml（Security Assertion Markup Language）

OpenID_Oauth.zip (2.7 MB)

摘要：OAuth協議爲用戶資源的受權提供了一個安全的、開放而又簡易的標準。與以往的受權方式不一樣之處是OAuth的受權不會使第三方觸及到用戶的賬號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就能夠申請得到該用戶資源的受權，所以OAuth是安全的。同時，任何第三方均可以使用 OAuth認證服務，任何服務提供商均可以實現自身的OAuth認證服務，於是OAuth是開放的。業界提供了OAuth的多種實現如 PHP，JavaScript，Java，Ruby等各類語言開發包，大大節約了程序員的時間，於是OAuth是簡易的。目前互聯網不少服務如Open API，不少大頭公司如Google，Yahoo，Microsoft等都提供了OAuth認證服務，這些都足以說明OAuth標準逐漸成爲開放資源受權的標準。html

1、OAuth產生的背景程序員

典型案例：若是一個用戶擁有兩項服務：一項服務是圖片在線存儲服務A，另外一個是圖片在線打印服務B。以下圖所示。因爲服務A與服務B是由兩家不一樣的服務提供商提供的，因此用戶在這兩家服務提供商的網站上各自注冊了兩個用戶，假設這兩個用戶名各不相同，密碼也各不相同。當用戶要使用服務B打印存儲在服務A上的圖片時，用戶該如何處理？法一：用戶可能先將待打印的圖片從服務A上下載下來並上傳到服務B上打印，這種方式安全但處理比較繁瑣，效率低下；法二：用戶將在服務A上註冊的用戶名與密碼提供給服務B，服務B使用用戶的賬號再去服務A處下載待打印的圖片，這種方式效率是提升了，可是安全性大大下降了，服務B可使用用戶的用戶名與密碼去服務A上查看甚至篡改用戶的資源。web

不少公司和我的都嘗試解決這類問題，包括Google、Yahoo、Microsoft，這也促使OAuth項目組的產生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發起的，目的在於爲API訪問受權提供一個開放的標準。OAuth規範的1.0版於2007年12月4日發佈。經過官方網址：http://OAuth.net能夠閱讀更多的相關信息。瀏覽器

2、OAuth簡介安全

在官方網站的首頁，能夠看到下面這段簡介：服務器

An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.cookie

大概意思是說OAuth是一種開放的協議，爲桌面程序或者基於BS的web應用提供了一種簡單的，標準的方式去訪問須要用戶受權的API服務。OAuth 相似於Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAuth認證受權具備如下特色：架構

1. 簡單：無論是OAuth服務提供者仍是應用開發者，都很容易於理解與使用；併發

2. 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；app

3. 開放：任何服務提供商均可以實現OAuth，任何軟件開發商均可以使用OAuth；

3、OAuth相關術語

在弄清楚OAuth流程以前，咱們先了解下OAuth的一些術語的定義：

OAuth相關的三個URL：
- Request Token URL: 獲取未受權的Request Token服務地址；
- User Authorization URL: 獲取用戶受權的Request Token服務地址；
- Access Token URL: 用受權的Request Token換取Access Token的服務地址；

OAuth相關的參數定義：
- OAuth_consumer_key: 使用者的ID，OAuth服務的直接使用者是開發者開發出來的應用。因此該參數值的獲取通常是要去OAuth服務提供商處註冊一個應用，再獲取該應用的OAuth_consumer_key。如Yahoo該值的註冊地址爲：https://developer.yahoo.com/dashboard/
- OAuth_consumer_secret：OAuth_consumer_key對應的密鑰。
- OAuth_signature_method: 請求串的簽名方法，應用每次向OAuth三個服務地址發送請求時，必須對請求進行簽名。簽名的方法有：HMAC-SHA一、RSA-SHA1與PLAINTEXT等三種。
- OAuth_signature: 用上面的簽名方法對請求的簽名。
- OAuth_timestamp: 發起請求的時間戳，其值是距1970 00:00:00 GMT的秒數，必須是大於0的整數。本次請求的時間戳必須大於或者等於上次的時間戳。
- OAuth_nonce: 隨機生成的字符串，用於防止請求的重放，防止外界的非法攻擊。
- OAuth_version: OAuth的版本號，可選，其值必須爲1.0。

OAuth HTTP響應代碼：

HTTP 400 Bad Request 請求錯誤
- Unsupported parameter 參數錯誤
- Unsupported signature method 簽名方法錯誤
- Missing required parameter 參數丟失
- Duplicated OAuth Protocol Parameter 參數重複
HTTP 401 Unauthorized 未受權
- Invalid Consumer Key 非法key
- Invalid / expired Token 失效或者非法的token
- Invalid signature 簽名非法
- Invalid / used nonce 非法的nonce

4、OAuth認證受權流程

在弄清楚了OAuth的術語後，咱們能夠對OAuth認證受權的流程進行初步認識。其實，簡單的來講，OAuth認證受權就三個步驟，三句話能夠歸納：

1. 獲取未受權的Request Token

2. 獲取用戶受權的Request Token

3. 用受權的Request Token換取Access Token

當應用拿到Access Token後，就能夠有權訪問用戶受權的資源了。你們肯能看出來了，這三個步驟不就是對應OAuth的三個URL服務地址嘛。一點沒錯，上面的三個步驟中，每一個步驟分別請求一個URL，而且收到相關信息，而且拿到上步的相關信息去請求接下來的URL直到拿到Access Token。具體的步驟以下圖所示：

具體每步執行信息以下：

A. 使用者（第三方軟件）向OAuth服務提供商請求未受權的Request Token。向Request Token URL發起請求，請求須要帶上的參數見上圖。

B. OAuth服務提供商贊成使用者的請求，並向其頒發未經用戶受權的OAuth_token與對應的OAuth_token_secret，並返回給使用者。

C. 使用者向OAuth服務提供商請求用戶受權的Request Token。向User Authorization URL發起請求，請求帶上上步拿到的未受權的token與其密鑰。

D. OAuth服務提供商將引導用戶受權。該過程可能會提示用戶，你想將哪些受保護的資源受權給該應用。此步可能會返回受權的Request Token也可能不返回。如Yahoo OAuth就不會返回任何信息給使用者。

E. Request Token 受權後，使用者將向Access Token URL發起請求，將上步受權的Request Token換取成Access Token。請求的參數見上圖，這個比第一步A多了一個參數就是Request Token。

F. OAuth服務提供商贊成使用者的請求，並向其頒發Access Token與對應的密鑰，並返回給使用者。

G. 使用者之後就可使用上步返回的Access Token訪問用戶受權的資源。

從上面的步驟能夠看出，用戶始終沒有將其用戶名與密碼等信息提供給使用者（第三方軟件），從而更安全。用OAuth實現背景一節中的典型案例：當服務 B（打印服務）要訪問用戶的服務A（圖片服務）時，經過OAuth機制，服務B向服務A請求未經用戶受權的Request Token後，服務A將引導用戶在服務A的網站上登陸，並詢問用戶是否將圖片服務受權給服務B。用戶贊成後，服務B就能夠訪問用戶在服務A上的圖片服務。整個過程服務B沒有觸及到用戶在服務A的賬號信息。以下圖所示，圖中的字母對應OAuth流程中的字母：

5、OAuth服務提供商

OAuth標準提出到如今不到兩年，但取得了很大成功。不只提供了各類語言的版本庫，甚至Google，Yahoo，Microsoft等等互聯網大頭都實現了OAuth協議。因爲OAuth的client包有不少，因此咱們就沒有必要在去本身寫，避免重複造輪子，直接拿過來用就好了。我使用了這些庫去訪問Yahoo OAuth服務，很不錯哦！下面就貼出一些圖片跟你們一塊兒分享下！

下圖是OAuth服務提供商引導用戶登陸（若用戶開始沒有登陸）

下圖是提示用戶將要受權給第三方應用，是否贊成受權的頁面

下圖提示用戶已受權成功的信息

一些服務提供商不只僅僅實現了OAuth協議上的功能，還提供了一些更友好的服務，好比管理第三方軟件的受權服務。下圖就是YAHOO管理軟件受權的頁面，用戶能夠取消都某些應用的受權。

原文地址： http://blog.csdn.net/hereweare2009/article/details/3968582

擴展閱讀：

http://zh.wikipedia.org/wiki/OAuth

http://baike.baidu.com/view/3948029.htm

1、OpenID簡介

OpenId是一個以用戶爲中心的數字身份識別框架，它具備開放、分散、自由等特性。OpenId的建立是基於這樣一個概念：咱們能夠經過URI（或者URL網址）來識別一個網站。一樣，咱們也能夠經過這樣的方式來識別一個用戶的身份。OpenId系統的身份認證就是經過 URI來認證用戶身份。目前絕大部分網站都是經過用戶名與密碼來登陸認證用戶身份，這就要求你們在每一個你要使用的網站上註冊一個賬號。若是使用 OpenId，你能夠在一個提供OpenId的網站上註冊一個OpenId，之後你可使用這個OpenId去登陸支持OpenId的網站。這正是一處注冊，處處使用的體現。

登陸一個支持 OpenID 的網站很是簡單（即使你是第一次訪問這個網站也是同樣）。只須要輸入你註冊好的 OpenID 用戶名，而後你登陸的網站會跳轉到你的 OpenID 服務網站，在你的 OpenID 服務網站輸入密碼（或者其它須要填寫的信息）驗證經過後，你會回到登陸的網站而且已經成功登陸。 OpenID 系統能夠應用於全部須要身份驗證的地方，既能夠應用於單點登陸系統，也能夠用於共享敏感數據時的身份認證。

除了一處註冊處處通行之外，OpenID 給全部支持 OpenID 的網站帶來了價值－－共享用戶資源。用戶能夠清楚的控制哪些信息能夠被共享，例如姓名、地址、電話號碼等。今天，OpenID 做爲以用戶爲中心的身份驗證系統已經爲數百萬的用戶提供了服務。

2、OpenID相關術語

End User：終端用戶，使用OP與RP的服務
Relying Party依賴方：簡稱RP，服務提供者，須要OP鑑權終端用戶的身份
OpenID Provider：OpenID提供者，簡稱OP，對用戶身份鑑權
Identifier標識符：標識符能夠是一個HTTP、HTTPS或者XRI(可擴展的資源標識)
User-Agent：實現了HTTP1.1協議的用戶瀏覽器
OP Endpoint URL：OP鑑權的URL，提供給RP使用
OP Identifier：OP提供給終端用戶的一個URI或者XRI,RP根據OP Identifier來解析出OP Endpoint URL與OP Version
User-Supplied Identifier：終端用戶使用的ID，多是OP提供的OpenID，也能夠是在RP註冊的ID。RP能夠根據User-Supplied Identifier來解析出OP Endpoint URL、OP Version與OP_Local Identifer
Claimed Identifier：終端用戶聲明本身身份的一個標誌，能夠是一個URI或者XRI
OP-Local Identifier：OP提供的局部ID

3、OpenID驗證流程

終端用戶請求登陸RP網站，用戶選擇了以OpenID方式來登陸
RP將OpenId的登陸界面返回給終端用戶
終端用戶以OpenID登錄RP網站
RP網站對用戶的OpenID進行標準化，此過程很是負責。因爲OpenID多是URI，也多是XRI，因此標準化方式各不相同。具體標準化過程是：若是OpenID以xri://、xri://$ip或者xri://$dns開頭，先去掉這些符號；而後對以下的字符串進行判斷，若是第一個字符是=、@、+、$、!，則視爲標準的XRI，不然視爲HTTP URL（若沒有http,爲其增長http://）。
RP發現OP，若是OpenId是XRI，就採用XRI解析，若是是URL，則用Yadis協議解析，若Yadis解析失敗，則用Http發現。
RP跟OP創建一個關聯。二者之間能夠創建一個安全通道，用於傳輸信息並下降交互次數。
OP處理RP的關聯請求
RP請求OP對用戶身份進行鑑權
OP對用戶鑑權，請求用戶進行登陸認證
用戶登陸OP
OP將鑑權結果返回給RP
RP對OP的結果進行分析