? 摘要：OAUTH協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全的、開放而又簡(jiǎn)易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是OAUTH的授權(quán)不會(huì)使第三方觸及到用戶的帳號(hào)信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請(qǐng)獲得該用戶資源的授權(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等各種語(yǔ)言開發(fā)包，大大節(jié)約了程序員的時(shí)間，因而OAUTH是簡(jiǎn)易的。目前互聯(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)生的背景

??? 典型案例：如果一個(gè)用戶擁有兩項(xiàng)服務(wù)：一項(xiàng)服務(wù)是圖片在線存儲(chǔ)服務(wù)A，另一個(gè)是圖片在線打印服務(wù)B。如下圖所示。由于服務(wù)A與服務(wù)B是由兩家不同的服務(wù)提供商提供的，所以用戶在這兩家服務(wù)提供商的網(wǎng)站上各自注冊(cè)了兩個(gè)用戶，假設(shè)這兩個(gè)用戶名各不相同，密碼也各不相同。當(dāng)用戶要使用服務(wù)B打印存儲(chǔ)在服務(wù)A上的圖片時(shí)，用戶該如何處理？法一：用戶可能先將待打印的圖片從服務(wù)A上下載下來并上傳到服務(wù)B上打印，這種方式安全但處理比較繁瑣，效率低下；法二：用戶將在服務(wù)A上注冊(cè)的用戶名與密碼提供給服務(wù)B，服務(wù)B使用用戶的帳號(hào)再去服務(wù)A處下載待打印的圖片，這種方式效率是提高了，但是安全性大大降低了，服務(wù)B可以使用用戶的用戶名與密碼去服務(wù)A上查看甚至篡改用戶的資源。

??? 很多公司和個(gè)人都嘗試解決這類問題，包括Google、Yahoo、Microsoft，這也促使OAUTH項(xiàng)目組的產(chǎn)生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發(fā)起的，目的在于為API訪問授權(quán)提供一個(gè)開放的標(biāo)準(zhǔn)。OAuth規(guī)范的1.0版于2007年12月4日發(fā)布。通過官方網(wǎng)址：http://oauth.net可以的相關(guān)信息。

二、OAUTH簡(jiǎn)介

??? 在官方網(wǎng)站的首頁(yè)，可以看到下面這段簡(jiǎn)介：

??? 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)用提供了一種簡(jiǎn)單的，標(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. 簡(jiǎn)單：不管是OAUTH服務(wù)提供者還是應(yīng)用開發(fā)者，都很容易于理解與使用；

2. 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；

3. 開放：任何服務(wù)提供商都可以實(shí)現(xiàn)OAUTH，任何軟件開發(fā)商都可以使用OAUTH；

?三、OAUTH相關(guān)術(shù)語(yǔ)

??? 在弄清楚OAUTH流程之前，我們先了解下OAUTH的一些術(shù)語(yǔ)的定義：

• OAUTH相關(guān)的三個(gè)URL：
  • Request Token URL: 獲取未授權(quán)的Request Token服務(wù)地址；
  • User Authorization URL: 獲取用戶授權(quán)的Request Token服務(wù)地址；
  • Access Token URL: 用授權(quán)的Request Token換取Access Token的服務(wù)地址；

• OAUTH相關(guān)的參數(shù)定義：
  • oauth_consumer_key: 使用者的ID，OAUTH服務(wù)的直接使用者是開發(fā)者開發(fā)出來的應(yīng)用。所以該參數(shù)值的獲取一般是要去OAUTH服務(wù)提供商處注冊(cè)一個(gè)應(yīng)用，再獲取該應(yīng)用的oauth_consumer_key。如Yahoo該值的注冊(cè)地址為：https://developer.yahoo.com/dashboard/
  • oauth_consumer_secret：oauth_consumer_key對(duì)應(yīng)的密鑰。
  • oauth_signature_method: 請(qǐng)求串的簽名方法，應(yīng)用每次向OAUTH三個(gè)服務(wù)地址發(fā)送請(qǐng)求時(shí)，必須對(duì)請(qǐng)求進(jìn)行簽名。簽名的方法有：HMAC-SHA1、RSA-SHA1與PLAINTEXT等三種。
  • oauth_signature: 用上面的簽名方法對(duì)請(qǐng)求的簽名。
  • oauth_timestamp: 發(fā)起請(qǐng)求的時(shí)間戳，其值是距1970 00:00:00 GMT的秒數(shù)，必須是大于0的整數(shù)。本次請(qǐng)求的時(shí)間戳必須大于或者等于上次的時(shí)間戳。
  • oauth_nonce: 隨機(jī)生成的字符串，用于防止請(qǐng)求的重放，防止外界的非法攻擊。
  • oauth_version: OAUTH的版本號(hào)，可選，其值必須為1.0。

??OAUTH HTTP響應(yīng)代碼：

• HTTP 400 Bad Request 請(qǐng)求錯(cuò)誤
  • Unsupported parameter 參數(shù)錯(cuò)誤
  • Unsupported signature method 簽名方法錯(cuò)誤
  • 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ù)語(yǔ)后，我們可以對(duì)OAUTH認(rèn)證授權(quán)的流程進(jìn)行初步認(rèn)識(shí)。其實(shí)，簡(jiǎn)單的來說，OAUTH認(rèn)證授權(quán)就三個(gè)步驟，三句話可以概括：

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)的資源了。大家肯能看出來了，這三個(gè)步驟不就是對(duì)應(yīng)OAUTH的三個(gè)URL服務(wù)地址嘛。一點(diǎn)沒錯(cuò)，上面的三個(gè)步驟中，每個(gè)步驟分別請(qǐng)求一個(gè)URL，并且收到相關(guān)信息，并且拿到上步的相關(guān)信息去請(qǐng)求接下來的URL直到拿到Access Token。具體的步驟如下圖所示：

?

具體每步執(zhí)行信息如下：

A. 使用者（第三方軟件）向OAUTH服務(wù)提供商請(qǐng)求未授權(quán)的Request Token。向Request Token URL發(fā)起請(qǐng)求，請(qǐng)求需要帶上的參數(shù)見上圖。

B. OAUTH服務(wù)提供商同意使用者的請(qǐng)求，并向其頒發(fā)未經(jīng)用戶授權(quán)的oauth_token與對(duì)應(yīng)的oauth_token_secret，并返回給使用者。

C. 使用者向OAUTH服務(wù)提供商請(qǐng)求用戶授權(quán)的Request Token。向User Authorization URL發(fā)起請(qǐng)求，請(qǐng)求帶上上步拿到的未授權(quán)的token與其密鑰。

D. OAUTH服務(wù)提供商將引導(dǎo)用戶授權(quán)。該過程可能會(huì)提示用戶，你想將哪些受保護(hù)的資源授權(quán)給該應(yīng)用。此步可能會(huì)返回授權(quán)的Request Token也可能不返回。如Yahoo OAUTH就不會(huì)返回任何信息給使用者。

E. Request Token 授權(quán)后，使用者將向Access Token URL發(fā)起請(qǐng)求，將上步授權(quán)的Request Token換取成Access Token。請(qǐng)求的參數(shù)見上圖，這個(gè)比第一步A多了一個(gè)參數(shù)就是Request Token。

F. OAUTH服務(wù)提供商同意使用者的請(qǐng)求，并向其頒發(fā)Access Token與對(duì)應(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請(qǐng)求未經(jīng)用戶授權(quán)的Request Token后，服務(wù)A將引導(dǎo)用戶在服務(wù)A的網(wǎng)站上登錄，并詢問用戶是否將圖片服務(wù)授權(quán)給服務(wù)B。用戶同意后，服務(wù)B就可以訪問用戶在服務(wù)A上的圖片服務(wù)。整個(gè)過程服務(wù)B沒有觸及到用戶在服務(wù)A的帳號(hào)信息。如下圖所示，圖中的字母對(duì)應(yīng)OAUTH流程中的字母：

?

五、OAUTH服務(wù)提供商

??? OAUTH標(biāo)準(zhǔn)提出到現(xiàn)在不到兩年，但取得了很大成功。不僅提供了各種語(yǔ)言的版本庫(kù)，甚至Google，Yahoo，Microsoft等等互聯(lián)網(wǎng)大頭都實(shí)現(xiàn)了OAUTH協(xié)議。由于OAUTH的client包有很多，所以我們就沒有必要在去自己寫，避免重復(fù)造輪子，直接拿過來用就行了。我使用了這些庫(kù)去訪問Yahoo OAUTH服務(wù)，很不錯(cuò)哦！下面就貼出一些圖片跟大家一起分享下！

??? 下圖是OAUTH服務(wù)提供商引導(dǎo)用戶登錄（若用戶開始沒有登錄）

???

??? 下圖是提示用戶將要授權(quán)給第三方應(yīng)用，是否同意授權(quán)的頁(yè)面

?

??? 下圖提示用戶已授權(quán)成功的信息

?

??? 一些服務(wù)提供商不僅僅僅實(shí)現(xiàn)了OAUTH協(xié)議上的功能，還提供了一些更友好的服務(wù)，比如管理第三方軟件的授權(quán)服務(wù)。下圖就是YAHOO管理軟件授權(quán)的頁(yè)面，用戶可以取消都某些應(yīng)用的授權(quán)。

總結(jié)

以上是生活随笔為你收集整理的OAUTH协议简介的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。