摘 要:OAUTH協(xié)議為用戶資源的授權(quán)提供了一個安全的、開放而又簡易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是OAUTH的授權(quán)不會使第三方觸及到用戶的帳號信 息(如用戶名與密碼),即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權(quán),因此OAUTH是安全的。同時(shí),任何第三方都可以使用 OAUTH認(rèn)證服務(wù),任何服務(wù)提供商都可以實(shí)現(xiàn)自身的OAUTH認(rèn)證服務(wù),因而OAUTH是開放的。業(yè)界提供了OAUTH的多種實(shí)現(xiàn)如 PHP,JavaScript,Java,Ruby等各種語言開發(fā)包,大大節(jié)約了程序員的時(shí)間,因而OAUTH是簡易的。目前互聯(lián)網(wǎng)很多服務(wù)如Open API,很多大頭公司如Google,Yahoo,Microsoft等都提供了OAUTH認(rèn)證服務(wù),這些都足以說明OAUTH標(biāo)準(zhǔn)逐漸成為開放資源授權(quán) 的標(biāo)準(zhǔn)。
'一、OAUTH'產(chǎn)生的背景
????典型案例:如果一個用戶擁有兩項(xiàng)服務(wù):一項(xiàng)服務(wù)是圖片在線存儲服務(wù)A, 另一個是圖片在線打印服務(wù)B。如下圖所示。由于服務(wù)A與服務(wù)B是由兩家不同的服務(wù)提供商提供的,所以用戶在這兩家服務(wù)提供商的網(wǎng)站上各自注冊了兩個用戶, 假設(shè)這兩個用戶名各不相同,密碼也各不相同。當(dāng)用戶要使用服務(wù)B打印存儲在服務(wù)A上的圖片時(shí),用戶該如何處理?法一:用戶可能先將待打印的圖片從服務(wù)A上 下載下來并上傳到服務(wù)B上打印,這種方式安全但處理比較繁瑣,效率低下;法二:用戶將在服務(wù)A上注冊的用戶名與密碼提供給服務(wù)B,服務(wù)B使用用戶的帳號再 去服務(wù)A處下載待打印的圖片,這種方式效率是提高了,但是安全性大大降低了,服務(wù)B可以使用用戶的用戶名與密碼去服務(wù)A上查看甚至篡改用戶的資源。
??? 很多公司和個人都嘗試解決這類問題,包括Google、Yahoo、Microsoft,這也促使OAUTH項(xiàng)目組的產(chǎn)生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發(fā)起的,目的在于為API訪問授權(quán)提供一個開放的標(biāo)準(zhǔn)。OAuth規(guī)范的1.0版于2007年12月4日發(fā)布。通過官方網(wǎng)址:http://oauth.net可以閱讀更多的相關(guān)信息。
'二、OAUTH'簡介
??? 在官方網(wǎng)站的首頁,可以看到下面這段簡介:
????An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.
??? 大概意思是說OAUTH是一種開放的協(xié)議,為桌面程序或者基于BS的web應(yīng)用提供了一種簡單的,標(biāo)準(zhǔn)的方式去訪問需要用戶授權(quán)的API服務(wù)。OAUTH 類似于Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAUTH認(rèn)證授權(quán)具有以下特點(diǎn):
1. 簡單:不管是OAUTH服務(wù)提供者還是應(yīng)用開發(fā)者,都很容易于理解與使用;
2. 安全:沒有涉及到用戶密鑰等信息,更安全更靈活;
3. 開放:任何服務(wù)提供商都可以實(shí)現(xiàn)OAUTH,任何軟件開發(fā)商都可以使用OAUTH;
?三、'OAUTH'相關(guān)術(shù)語
??? 在弄清楚OAUTH流程之前,我們先了解下OAUTH的一些術(shù)語的定義:
-
Tudou OAuth 相關(guān)的三個URL:
- Request Token URL: 獲取未授權(quán)的Request Token服務(wù)地址 ;
- http://api.tudou.com/auth/request_token.oauth
- User Authorization URL: 獲取用戶授權(quán)的Request Token服務(wù)地址;
- http://api.tudou.com/auth/authorize.oauth
- Access Token URL: 用授權(quán)的Request Token換取Access Token的服務(wù)地址;
- http://api.tudou.com/auth/access_token.oauth
-
OAUTH'
相關(guān)的參數(shù)定義:
- oauth_consumer_key: 使用者的ID,OAUTH服務(wù)的直接使用者是開發(fā)者開發(fā)出來的應(yīng)用。所以該參數(shù)值的獲取一般是要去OAUTH服務(wù)提供商處注冊一個應(yīng)用,再獲取該應(yīng)用的oauth_consumer_key。如Yahoo該值的注冊地址為: https://developer.yahoo.com/dashboard/
- oauth_consumer_secret:oauth_consumer_key對應(yīng)的密鑰。
- oauth_signature_method: 請求串的簽名方法,應(yīng)用每次向OAUTH三個服務(wù)地址發(fā)送請求時(shí),必須對請求進(jìn)行簽名。簽名的方法有:HMAC-SHA1、RSA-SHA1與PLAINTEXT等三種。
- oauth_signature: 用上面的簽名方法對請求的簽名。
- oauth_timestamp: 發(fā)起請求的時(shí)間戳,其值是距1970 00:00:00 GMT的秒數(shù),必須是大于0的整數(shù)。本次請求的時(shí)間戳必須大于或者等于上次的時(shí)間戳。
- oauth_nonce: 隨機(jī)生成的字符串,用于防止請求的重放,防止外界的非法攻擊。
- oauth_version: OAUTH的版本號,可選,其值必須為1.0。
? ?OAUTH HTTP 響應(yīng)代碼:</span
-
HTTP 400 Bad Request 請求錯誤
- Unsupported parameter 參數(shù)錯誤
- Unsupported signature method 簽名方法錯誤
- Missing required parameter 參數(shù)丟失
- Duplicated OAuth Protocol Parameter 參數(shù)重復(fù)
-
HTTP 401 Unauthorized 未授權(quán)
- Invalid Consumer Key 非法key
- Invalid / expired Token 失效或者非法的token
- Invalid signature 簽名非法
- Invalid / used nonce 非法的nonce
'四、OAUTH'認(rèn)證授權(quán)流程
??? 在弄清楚了OAUTH的術(shù)語后,我們可以對OAUTH認(rèn)證授權(quán)的流程進(jìn)行初步認(rèn)識。其實(shí),簡單的來說,OAUTH認(rèn)證授權(quán)就三個步驟,三句話可以概括:
1. 獲取未授權(quán)的Request Token
2. 獲取用戶授權(quán)的Request Token
3. 用授權(quán)的Request Token換取Access Token
??? 當(dāng)應(yīng)用拿到Access Token后,就可以有權(quán)訪問用戶授權(quán)的資源了。大家肯能看出來了,這三個步驟不就是對應(yīng)OAUTH的三個URL服務(wù)地址嘛。一點(diǎn)沒錯,上面的三個步驟 中,每個步驟分別請求一個URL,并且收到相關(guān)信息,并且拿到上步的相關(guān)信息去請求接下來的URL直到拿到Access Token。具體的步驟如下圖所示:
具體每步執(zhí)行信息如下:
A. 使用者(第三方軟件)向OAUTH服務(wù)提供商請求未授權(quán)的Request Token。向Request Token URL發(fā)起請求,請求需要帶上的參數(shù)見上圖。
B. OAUTH服務(wù)提供商同意使用者的請求,并向其頒發(fā)未經(jīng)用戶授權(quán)的oauth_token與對應(yīng)的oauth_token_secret,并返回給使用者。
C. 使用者向OAUTH服務(wù)提供商請求用戶授權(quán)的Request Token。向User Authorization URL發(fā)起請求,請求帶上上步拿到的未授權(quán)的token與其密鑰。
D. OAUTH服務(wù)提供商將引導(dǎo)用戶授權(quán)。該過程可能會提示用戶,你想將哪些受保護(hù)的資源授權(quán)給該應(yīng)用。此步可能會返回授權(quán)的Request Token也可能不返回。如Yahoo OAUTH就不會返回任何信息給使用者。
E. Request Token 授權(quán)后,使用者將向Access Token URL發(fā)起請求,將上步授權(quán)的Request Token換取成Access Token。請求的參數(shù)見上圖,這個比第一步A多了一個參數(shù)就是Request Token。
F. OAUTH服務(wù)提供商同意使用者的請求,并向其頒發(fā)Access Token與對應(yīng)的密鑰,并返回給使用者。
G. 使用者以后就可以使用上步返回的Access Token訪問用戶授權(quán)的資源。
??? 從上面的步驟可以看出,用戶始終沒有將其用戶名與密碼等信息提供給使用者(第三方軟件),從而更安全。用OAUTH實(shí)現(xiàn)背景一節(jié)中的典型案例:當(dāng)服務(wù) B(打印服務(wù))要訪問用戶的服務(wù)A(圖片服務(wù))時(shí),通過OAUTH機(jī)制,服務(wù)B向服務(wù)A請求未經(jīng)用戶授權(quán)的Request Token后,服務(wù)A將引導(dǎo)用戶在服務(wù)A的網(wǎng)站上登錄,并詢問用戶是否將圖片服務(wù)授權(quán)給服務(wù)B。用戶同意后,服務(wù)B就可以訪問用戶在服務(wù)A上的圖片服務(wù)。 整個過程服務(wù)B沒有觸及到用戶在服務(wù)A的帳號信息。如下圖所示,圖中的字母對應(yīng)OAUTH流程中的字母:
'五、OAUTH'服務(wù)提供商
??? OAUTH標(biāo)準(zhǔn)提出到現(xiàn)在不到兩年,但取得了很大成功。不僅提供了各種語言的版本庫,甚至Google,Yahoo,Microsoft等等互聯(lián)網(wǎng)大頭都 實(shí)現(xiàn)了OAUTH協(xié)議。由于OAUTH的client包有很多,所以我們就沒有必要在去自己寫,避免重復(fù)造輪子,直接拿過來用就行了。我使用了這些庫去訪 問Yahoo OAUTH服務(wù),很不錯哦!下面就貼出一些圖片跟大家一起分享下!
??? 下圖是OAUTH服務(wù)提供商引導(dǎo)用戶登錄(若用戶開始沒有登錄)
???
??? 下圖是提示用戶將要授權(quán)給第三方應(yīng)用,是否同意授權(quán)的頁面
??? 下圖提示用戶已授權(quán)成功的信息
??? 一些服務(wù)提供商不僅僅僅實(shí)現(xiàn)了OAUTH協(xié)議上的功能,還提供了一些更友好的服務(wù),比如管理第三方軟件的授權(quán)服務(wù)。下圖就是YAHOO管理軟件授權(quán)的頁面,用戶可以取消都某些應(yīng)用的授權(quán)。
摘自:[http://blog.csdn.net/hereweare2009/archive/2009/03/08/3968582.aspx]