摘 要：OAUTH協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是OAUTH的授權不會使第三方觸及到用戶的帳號信 息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAUTH是安全的。同時，任何第三方都可以使用 OAUTH認證服務，任何服務提供商都可以實現自身的OAUTH認證服務，因而OAUTH是開放的。業界提供了OAUTH的多種實現如 PHP，JavaScript，Java，Ruby等各種語言開發包，大大節約了程序員的時間，因而OAUTH是簡易的。目前互聯網很多服務如Open API，很多大頭公司如Google，Yahoo，Microsoft等都提供了OAUTH認證服務，這些都足以說明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日發布。通過官方網址：http://oauth.net可以閱讀更多的相關信息。
'二、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、Yahoo's BBAuth、 Facebook Auth等。OAUTH認證授權具有以下特點：
1. 簡單：不管是OAUTH服務提供者還是應用開發者，都很容易于理解與使用；
2. 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；
3. 開放：任何服務提供商都可以實現OAUTH，任何軟件開發商都可以使用OAUTH；
?三、'OAUTH'相關術語
??? 在弄清楚OAUTH流程之前，我們先了解下OAUTH的一些術語的定義：
-
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-SHA1、RSA-SHA1與PLAINTEXT等三種。
-
oauth_signature: 用上面的簽名方法對請求的簽名。
-
oauth_timestamp: 發起請求的時間戳，其值是距1970 00:00:00 GMT的秒數，必須是大于0的整數。本次請求的時間戳必須大于或者等于上次的時間戳。
-
oauth_nonce: 隨機生成的字符串，用于防止請求的重放，防止外界的非法攻擊。
-
oauth_version: OAUTH的版本號，可選，其值必須為1.0。
?
?OAUTH HTTP
響應代碼：</span
-
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
'四、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流程中的字母：
'五、OAUTH'服務提供商
??? OAUTH標準提出到現在不到兩年，但取得了很大成功。不僅提供了各種語言的版本庫，甚至Google，Yahoo，Microsoft等等互聯網大頭都 實現了OAUTH協議。由于OAUTH的client包有很多，所以我們就沒有必要在去自己寫，避免重復造輪子，直接拿過來用就行了。我使用了這些庫去訪 問Yahoo OAUTH服務，很不錯哦！下面就貼出一些圖片跟大家一起分享下！
??? 下圖是OAUTH服務提供商引導用戶登錄（若用戶開始沒有登錄）
???
??? 下圖是提示用戶將要授權給第三方應用，是否同意授權的頁面
??? 下圖提示用戶已授權成功的信息
??? 一些服務提供商不僅僅僅實現了OAUTH協議上的功能，還提供了一些更友好的服務，比如管理第三方軟件的授權服務。下圖就是YAHOO管理軟件授權的頁面，用戶可以取消都某些應用的授權。
摘自:[http://blog.csdn.net/hereweare2009/archive/2009/03/08/3968582.aspx]