如果你開車去酒店赴宴，你經(jīng)常會(huì)苦于找不到停車位而耽誤很多時(shí)間。是否有好辦法可以避免這個(gè)問題呢？有的，聽說有一些豪車的車主就不擔(dān)心這個(gè)問題。豪車一般配備兩種鑰匙：主鑰匙和泊車鑰匙。當(dāng)你到酒店后，只需要將泊車鑰匙交給服務(wù)生，停車的事情就由服務(wù)生去處理。與主鑰匙相比，這種泊車鑰匙的使用功能是受限制的：它只能啟動(dòng)發(fā)動(dòng)機(jī)并讓車行駛一段有限的距離，可以鎖車，但無法打開后備箱，無法使用車內(nèi)其他設(shè)備。這里就體現(xiàn)了一種簡單的“開放授權(quán)”思想：通過一把泊車鑰匙，車主便能將汽車的部分使用功能（如啟動(dòng)發(fā)動(dòng)機(jī)、行駛一段有限的距離）授權(quán)給服務(wù)生。

授權(quán)是一個(gè)古老的概念，它是一個(gè)多用戶系統(tǒng)必須支持的功能特性。比如，Alice和Bob都是Google的用戶，那么Alice應(yīng)該可以將自己的照片授權(quán)給Bob訪問。但請(qǐng)注意到，這種授權(quán)是一種封閉授權(quán)，它只支持系統(tǒng)內(nèi)部用戶之間的相互授權(quán)，而不能支持與其他外部系統(tǒng)或用戶之間的授權(quán)。比如說，Alice想使用“網(wǎng)易印像服務(wù)”將她的部分照片沖印出來，她怎么能做到呢？

肯定有人會(huì)說，Alice可以將自己的Google用戶名和密碼告訴網(wǎng)易印像服務(wù)，事情不就解決了嗎？是的，但只有毫不關(guān)注安全和隱私的同學(xué)才會(huì)出此“絕招”。那么我們就來想一想，這一“絕招”存在哪些問題？(1) 網(wǎng)易印像服務(wù)可能會(huì)緩存Alice的用戶名和密碼，而且可能沒有加密保護(hù)。它一旦遭到攻擊，Alice就會(huì)躺著中槍。(2) 網(wǎng)易印像服務(wù)可以訪問Alice在Google上的所有資源，Alice無法對(duì)他們進(jìn)行最小的權(quán)限控制，比如只允許訪問某一張照片，1小時(shí)內(nèi)訪問有效。(3) Alice無法撤消她的單個(gè)授權(quán)，除非Alice更新密碼。

在以Web服務(wù)為核心的云計(jì)算時(shí)代，像用戶Alice的這種授權(quán)需求變得日益迫切與興盛，“開放授權(quán)(Open Authorization)”也正因此而生，意在幫助Alice將她的資源授權(quán)給第三方應(yīng)用，支持細(xì)粒度的權(quán)限控制，并且不會(huì)泄漏Alice的密碼或其它認(rèn)證憑據(jù)。

根據(jù)應(yīng)用場(chǎng)景的不同，目前實(shí)現(xiàn)開放授權(quán)的方法分為兩種：一種是使用OAuth協(xié)議[1]；另一種是使用IAM服務(wù)[2]。OAuth協(xié)議主要適用于針對(duì)個(gè)人用戶對(duì)資源的開放授權(quán)，比如Google的用戶Alice。OAuth的特點(diǎn)是“現(xiàn)場(chǎng)授權(quán)”或“在線授權(quán)”：客戶端主要通過瀏覽器去訪問資源，授權(quán)時(shí)需要認(rèn)證Alice的資源所有者身份，并且需要Alice現(xiàn)場(chǎng)審批。OAuth一般在SNS服務(wù)中廣泛使用，如微博。IAM服務(wù)則不同，它的特點(diǎn)是“預(yù)先授權(quán)”或“離線授權(quán)”：客戶端主要通過REST API方式去訪問資源，資源所有者可以預(yù)先知道第三方應(yīng)用所需要的資源請(qǐng)求，一次授權(quán)之后，很少會(huì)變更。IAM服務(wù)一般在云計(jì)算服務(wù)中使用，如AWS服務(wù)、阿里云計(jì)算服務(wù)。

本文主要介紹OAuth開放授權(quán)。關(guān)于以IAM服務(wù)提供的開放授權(quán)，我將在另一篇博文中介紹。下面我來介紹OAuth 2.0協(xié)議、協(xié)議的實(shí)例化描述、安全性分析。

從引言部分的描述我們可以看出，OAuth的參與實(shí)體至少有如下三個(gè)：

· RO (resource owner): 資源所有者，對(duì)資源具有授權(quán)能力的人。如上文中的用戶Alice。

· RS (resource server): 資源服務(wù)器，它存儲(chǔ)資源，并處理對(duì)資源的訪問請(qǐng)求。如Google資源服務(wù)器，它所保管的資源就是用戶Alice的照片。

· Client: 第三方應(yīng)用，它獲得RO的授權(quán)后便可以去訪問RO的資源。如網(wǎng)易印像服務(wù)。

· AS (authorization server): 授權(quán)服務(wù)器，它認(rèn)證RO的身份，為RO提供授權(quán)審批流程，并最終頒發(fā)授權(quán)令牌(Access Token)。讀者請(qǐng)注意，為了便于協(xié)議的描述，這里只是在邏輯上把AS與RS區(qū)分開來；在物理上，AS與RS的功能可以由同一個(gè)服務(wù)器來提供服務(wù)。

在開放授權(quán)中，第三方應(yīng)用(Client)可能是一個(gè)Web站點(diǎn)，也可能是在瀏覽器中運(yùn)行的一段JavaScript代碼，還可能是安裝在本地的一個(gè)應(yīng)用程序。這些第三方應(yīng)用都有各自的安全特性。對(duì)于Web站點(diǎn)來說，它與RO瀏覽器是分離的，它可以自己保存協(xié)議中的敏感數(shù)據(jù)，這些密鑰可以不暴露給RO；對(duì)于JavaScript代碼和本地安全的應(yīng)用程序來說，它本來就運(yùn)行在RO的瀏覽器中，RO是可以訪問到Client在協(xié)議中的敏感數(shù)據(jù)。

OAuth為了支持這些不同類型的第三方應(yīng)用，提出了多種授權(quán)類型，如授權(quán)碼 (Authorization Code Grant)、隱式授權(quán) (Implicit Grant)、RO憑證授權(quán) (Resource Owner Password Credentials Grant)、Client憑證授權(quán) (Client Credentials Grant)。由于本文旨在幫助用戶理解OAuth協(xié)議，所以我將先介紹這些授權(quán)類型的基本思路，然后選擇其中最核心、最難理解、也是最廣泛使用的一種授權(quán)類型——“授權(quán)碼”，進(jìn)行深入的介紹。

(1) Client請(qǐng)求RO的授權(quán)，請(qǐng)求中一般包含：要訪問的資源路徑，操作類型，Client的身份等信息。

(2) RO批準(zhǔn)授權(quán)，并將“授權(quán)證據(jù)”發(fā)送給Client。至于RO如何批準(zhǔn)，這個(gè)是協(xié)議之外的事情。典型的做法是，AS提供授權(quán)審批界面，讓RO顯式批準(zhǔn)。這個(gè)可以參考下一節(jié)實(shí)例化分析中的描述。

(3) Client向AS請(qǐng)求“訪問令牌(Access Token)”。此時(shí)，Client需向AS提供RO的“授權(quán)證據(jù)”，以及Client自己身份的憑證。

(4) AS驗(yàn)證通過后，向Client返回“訪問令牌”。訪問令牌也有多種類型，若為bearer類型，那么誰持有訪問令牌，誰就能訪問資源。

(5) Client攜帶“訪問令牌”訪問RS上的資源。在令牌的有效期內(nèi)，Client可以多次攜帶令牌去訪問資源。

(6) RS驗(yàn)證令牌的有效性，比如是否偽造、是否越權(quán)、是否過期，驗(yàn)證通過后，才能提供服務(wù)。

(1) Client初始化協(xié)議的執(zhí)行流程。首先通過HTTP 302來重定向RO用戶代理到AS。Client在redirect_uri中應(yīng)包含如下參數(shù)：client_id, scope (描述被訪問的資源), redirect_uri (即Client的URI), state (用于抵制CSRF攻擊). 此外，請(qǐng)求中還可以包含access_type和approval_prompt參數(shù)。當(dāng)approval_prompt=force時(shí)，AS將提供交互頁面，要求RO必須顯式地批準(zhǔn)（或拒絕）Client的此次請(qǐng)求。如果沒有approval_prompt參數(shù)，則默認(rèn)為RO批準(zhǔn)此次請(qǐng)求。當(dāng)access_type=offline時(shí)，AS將在頒發(fā)access_token時(shí)，同時(shí)還會(huì)頒發(fā)一個(gè)refresh_token。因?yàn)閍ccess_token的有效期較短（如3600秒），為了優(yōu)化協(xié)議執(zhí)行流程，offline方式將允許Client直接持refresh_token來換取一個(gè)新的access_token。

(2) AS認(rèn)證RO身份，并提供頁面供RO決定是否批準(zhǔn)或拒絕Client的此次請(qǐng)求（當(dāng)approval_prompt=force時(shí)）。

(3) 若請(qǐng)求被批準(zhǔn)，AS使用步驟(1)中Client提供的redirect_uri重定向RO用戶代理到Client。redirect_uri須包含authorization_code，以及步驟1中Client提供的state。若請(qǐng)求被拒絕，AS將通過redirect_uri返回相應(yīng)的錯(cuò)誤信息。

(4) Client拿authorization_code去訪問AS以交換所需的access_token。Client請(qǐng)求信息中應(yīng)包含用于認(rèn)證Client身份所需的認(rèn)證數(shù)據(jù)，以及上一步請(qǐng)求authorization_code時(shí)所用的redirect_uri。

協(xié)議所涉及到的細(xì)節(jié)都已經(jīng)在圖3上了，所以不打算再做詳細(xì)介紹了。若看懂了此圖，OAuth2.0就理解了。

讀者請(qǐng)注意，在步驟(4)中，Client需要拿“授權(quán)碼”去換“授權(quán)令牌”時(shí)，Client需要向AS證明自己的身份，即證明自己就是步驟(2)中Alice批準(zhǔn)授權(quán)時(shí)的Grantee。這個(gè)身份證明的方法主要有兩種（圖3中使用了第1種）：
(1) 通過https直接將client_secret發(fā)送給AS，因?yàn)閏lient_secret是由Client與AS所共享，所以只要傳送client_secret的信道安全即可。
(2) 通過消息認(rèn)證碼來認(rèn)證Client身份，典型的算法有HMAC-SHA1。在這種方式下，Client無需傳送client_secret，只需發(fā)送消息請(qǐng)求的signature即可。由于不需要向AS傳遞敏感數(shù)據(jù)，所以它只需要使用http即可。

此外， 在步驟(2)中，Google授權(quán)服務(wù)器需要認(rèn)證Alice的RO身份，并提供授權(quán)界面給Alice進(jìn)行授權(quán)審批。今天Google提供的實(shí)例如圖4、圖5所示，僅供讀者理解OAuth這種“現(xiàn)場(chǎng)授權(quán)”或"在線授權(quán)"的含義。

(1) 瀏覽器的redirect_uri是一個(gè)不安全信道，此方式不適合于傳遞敏感數(shù)據(jù)（如access_token）。因?yàn)閡ri可能通過HTTP referrer被傳遞給其它惡意站點(diǎn)，也可能存在于瀏覽器cacher或log文件中，這就給攻擊者盜取access_token帶來了很多機(jī)會(huì)。另外，此協(xié)議也不應(yīng)該假設(shè)RO用戶代理的行為是可信賴的，因?yàn)镽O的瀏覽器可能早已被攻擊者植入了跨站腳本用來監(jiān)聽access_token。因此，access_token通過RO的用戶代理傳遞給Client，會(huì)顯著擴(kuò)大access_token被泄露的風(fēng)險(xiǎn)。 但authorization_code可以通過redirect_uri方式來傳遞，是因?yàn)閍uthorization_code并不像access_token一樣敏感。即使authorization_code被泄露，攻擊者也無法直接拿到access_token，因?yàn)槟胊uthorization_code去交換access_token是需要驗(yàn)證Client的真實(shí)身份。也就是說，除了Client之外，其他人拿authorization_code是沒有用的。 此外，access_token應(yīng)該只頒發(fā)給Client使用，其他任何主體（包括RO）都不應(yīng)該獲取access_token。協(xié)議的設(shè)計(jì)應(yīng)能保證Client是唯一有能力獲取access_token的主體。引入authorization_code之后，便可以保證Client是access_token的唯一持有人。當(dāng)然，Client也是唯一的有義務(wù)需要保護(hù)access_token不被泄露。

(2) 引入authorization_code還會(huì)帶來如下的好處。由于協(xié)議需要驗(yàn)證Client的身份，如果不引入authorization_code，這個(gè)Client的身份認(rèn)證只能通過第1步的redirect_uri來傳遞。同樣由于redirect_uri是一個(gè)不安全信道，這就額外要求Client必須使用數(shù)字簽名技術(shù)來進(jìn)行身份認(rèn)證，而不能用簡單的密碼或口令認(rèn)證方式。引入authorization_code之后，AS可以直接對(duì)Client進(jìn)行身份認(rèn)證（見步驟4和5），而且可以支持任意的Client認(rèn)證方式（比如，簡單地直接將Client端密鑰發(fā)送給AS）。