OAuth協議

      OAUTH協議爲用戶資源的受權提供了一個安全的、開放而又簡易的標準。與以往的受權方式不一樣之處是OAUTH的受權不會使第三方觸及到用戶的賬號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就能夠申請得到該用戶資源的受權，所以OAUTH是安全的。

        OAUTH協議爲用戶資源的受權提供了一個安全的、開放而又簡易的標準。同時，任何第三方均可以使用OAUTH認證服務，任何服務提供商均可以實現自身的OAUTH認證服務，於是OAUTH是開放的。業界提供了OAUTH的多種實現如PHP、JavaScript，Java，Ruby等各類語言開發包，大大節約了程序員的時間，於是OAUTH是簡易的。互聯網不少服務如Open API，不少大公司如Google，Yahoo，Microsoft等都提供了OAUTH認證服務，這些都足以說明OAUTH標準逐漸成爲開放資源受權的標準。    

      An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.大概意思是說OAUTH是一種開放的協議，爲 桌面程序或者基於BS的web應用提供了一種簡單的，標準的方式去訪問須要用戶受權的API服務。OAUTH相似於Flickr Auth、Google's AuthSub[1] 、Yahoo's BBAuth、 Facebook Auth等。

 

 協議特色 

(1). 簡單：不論是OAUTH服務提供者仍是應用開發者，都很易於理解與使用；

(2). 安全：沒有涉及到用戶密鑰等信息，更安全更靈活； （這種特色能夠聯想到，咱們我的申請的雲存儲資源能夠做爲公共存儲資源給多用戶使用（暫時設想，待驗證））

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

 

典型案例：若是一個用戶擁有兩項服務：一項服務是圖片在線存儲服務A，另外一個是圖片在線打印服務B。如

下圖所示。因爲服務A與服務B是由兩家不一樣的服務提供商提供的，因此用戶在這兩家服務提供商的網站上各自注冊了兩個用戶，假設這兩個用戶名各不相同，密碼也各不相同。當用戶

要使用服務B打印存儲在服務A上的圖片時，用戶該如何處理？法一：用戶可能先將待打印的圖片從服務A上下載下來並上傳到服務B上打印，這種方式安全但處理比較繁瑣，效率低下；法二：用戶將在服務A上註冊的用戶名與密碼提供給服務B，服務B使用用戶的 賬號再去服務A處下載待打印的圖片，這種方式效率是提升了，可是安全性大大下降了，服務B可使用用戶的用戶名與密碼去服務A上查看甚至篡改用戶的資源。

不少公司和我的都嘗試解決這類問題，包括Google、Yahoo、Microsoft，這也促使OAUTH項目組的產生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發起的，目的在於爲API訪問受權提供一個開放的標準。OAuth規範的1.0版於2007年12月4日發佈。

 

      因此對於雲計算整合的後端服務須要融合，必需要使用新的安全機制進行驗證，傳統模式已經沒法跟上發展需求。對於應用軟件集成商來講，不能讓前端客戶感知到後端的服務是多麼複雜或者還須要客戶進行多個登錄和驗證。

 

      不少公司和我的都嘗試解決這類問題，包括Google、Yahoo、Microsoft，這也促使OAUTH項目組的產生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發起的，目的在於爲API訪問受權提供一個開放的標準。OAuth規範的1.0版於2007年12月4日發佈。

 

三個URL：

Request Token URL: 獲取未受權的Request Token服務地址；

User Authorization URL: 獲取用戶受權的Request Token服務地址；

Access Token URL: 用受權的Request Token換取Access Token的服務地址；

 

 

參數定義：

OAUTH_consumer_key: 使用者的ID，OAUTH服務的直接使用者是開發者開發出來的應用。因此該參數值的獲取通常是要去OAUTH服務提供商處註冊一個應用，再獲取該應用的OAUTH_consumer_key。

OAUTH_consumer_secret：OAUTH_consumer_key對應的密鑰。

因此：註冊應用服務生成的consumer_key和consumer_secret就比較重要了。

OAUTH_token:OAUTH進行到最後一步獲得的一個「令牌」，經過此「令牌」請求，就能夠去擁有資源的網站抓取任意有權限能夠被抓取的資源。

OAUTH_token_secret:OAUTH_token對應的私鑰。

OAUTH_signature_method: 請求串的簽名方法，應用每次向OAUTH三個服務地址發送請求時，必須對請求進行簽名。簽名的方法有：HMAC-SHA一、RSA-SHA1與PLAINTEXT等三種。

OAUTH_signature: 用上面的簽名方法對請求的簽名。

OAUTH_timestamp: 發起請求的 時間戳，其值是距1970 00:00:00 GMT的秒數，必須是大於0的整數。本次請求的 時間戳必須大於或者等於上次的時間戳。

OAUTH_nonce: 隨機生成的字符串，用於防止請求的重複，防止外界的非法攻擊。

OAUTH_version: OAUTH的版本號。

 

認證流程

獲取未受權的request token

請求參數：

OAUTH_consumer_key:消費方鍵值。

OAUTH_signature_method:消費方簽署本請求所用的簽名方法。

OAUTH_signature:簽名，定義於簽署請求 (簽署請求)。

OAUTH_timestamp:定義於 Nonceand Timestamp (單次值與 時間戳)。

OAUTH_nonce:定義於 Nonceand Timestamp (單次值與 時間戳)。

OAUTH_version:可選。

額外參數:由服務提供方定義的任意額外參數

服務方返回結果，響應包含以下參數：

OAUTH_token:請求令牌

OAUTH_token_secret:令牌密鑰

附加參數:由服務提供方定義的任意參數。

獲取用戶受權的request token

請求參數：

OAUTH_token:可選。在前述步驟中得到的請求令牌。服務提供方能夠聲明此參數爲必須，也能夠容許不包含在受權URL中並提示用戶手工輸入。

OAUTH_callback:可選。消費方能夠指定一個URL，當 獲取用戶受權 (獲取用戶受權)成功後，服務提供方將重定向用戶到這個URL。

附加參數:由服務提供方定義的任意參數。

服務提供方將用戶引導回消費方

若是消費方在OAUTH_callback中提供了回調URL(在消費方引導用戶至服務提供方 (消費方引導用戶至服務提供方)中描述)，則服務提供方構造一個HTTP GET請求URL，重定向用戶瀏覽器到該URL，幷包含以下參數：

OAUTH_token:被用戶受權或否決的請求令牌

回調URL能夠包含消費方提供的查詢參數，服務提供方必須保持已有查詢不變並追加OAUTH_token參數。

用受權的request token換取Access Token

消費方請求訪問令牌參數：

OAUTH_consumer_key:消費方鍵值。

OAUTH_token:以前獲取的請求令牌。

OAUTH_signature_method:消費方使用的簽署方法。

OAUTH_signature:簽署請求 (簽署請求)中定義的簽名。

OAUTH_timestamp:在單次值與時間戳 (單次值與時間戳)中定義。

OAUTH_nonce:在單次值與時間戳 (單次值與時間戳)中定義。

OAUTH_version:版本號，可選。

返回參數：

OAUTH_token:訪問令牌。

OAUTH_token_secret:令牌密鑰。

訪問受保護資源

請求參數：

OAUTH_consumer_key:消費方鍵值。

OAUTH_token:訪問令牌。

OAUTH_signature_method:消費方使用的簽署方法。

OAUTH_signature:簽署請求 (簽署請求)中定義的簽名。

OAUTH_timestamp:定義於單次值與時間戳 (單次值與時間戳).

OAUTH_nonce:定義於單次值與時間戳 (單次值與時間戳).

OAUTH_version:版本號，可選。

附加參數:服務提供方指定的附加參數。

 

 

受權流程編輯

在弄清楚了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流程中的字母：

OAUTH流程

 

版本編輯

OAuth Core 1.0 版本發佈於2007年12月4日，因爲存在可被會話定向攻擊(session fixation attack)的緣故，2009年6月24日發佈了OAuth Core 1.0 Revision A 版本。最終在2010年4月，OAuth成爲了RFC標準： RFC 5849: The OAuth 1.0 Protocol。

OAuth 2.0的草案是在2010年5月初在IETF發佈的。OAuth 2.0是OAuth協議的下一版本，但不 向後兼容OAuth 1.0。 OAuth 2.0關注 客戶端開發者的簡易性，同時爲Web應用， 桌面應用和手機，和起居室設備提供專門的認證流程。規範還在IETF OAuth 工做組的開發中，按照Eran Hammer-Lahav的說法，OAuth於2010年底完成。