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 web, mobile and desktop applications.

大概意思是說OAUTH是一種開放的協議，為桌面、手機或web應用提供了一種簡單的，標準的方式去訪問需要用戶授權的API服務。OAUTH類似於Flickr Auth、Google's AuthSub、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日發布。

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對應的密鑰。

OAUTH_token:OAUTH進行到最後一步得到的一個“令牌”，通過此“令牌”請求，就可以去擁有資源的網站抓取任意有許可權可以被抓取的資源。

OAUTH_token_secret:OAUTH_token對應的私鑰。

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

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

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

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

OAUTH_version: OAUTH的版本號。

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

獲取未授權的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 OA UTH就不會返回任何信息給使用者。

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 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年末完成。