OAUTH協定為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是OAUTH的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAUTH是安全的。oAuth是Open Authorization的簡寫。
基本介紹
- 中文名：oAuth
- 本質：一種開放的協定
- 對象：第三方可以使用OAUTH認證服務
- 語言：PHP、JavaScript，Java
- 特點：安全的、開放而又簡易
- 類似協定：Flickr Auth
定義,協定特點,產生背景,相關術語,三個URL,參數定義,回響代碼,認證流程,授權流程,版本,
定義
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日發布。
相關術語
三個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對應的密鑰。
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_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就不會返回任何信息給使用者。
OAUTH流程
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 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。
