【51CTO.com原創(chuàng)稿件】在互聯(lián)網(wǎng)蓬勃發(fā)展的今天，互聯(lián)網(wǎng)應(yīng)用層出不窮，每個(gè)應(yīng)用專注的領(lǐng)域和方法也不相同。

[[435855]]

圖片來自 包圖網(wǎng)

為了給用戶更好的使用體驗(yàn)，一個(gè)互聯(lián)網(wǎng)應(yīng)用會(huì)請(qǐng)求用戶授權(quán)獲取另外一個(gè)應(yīng)用，在獲取授權(quán)之后就可以獲取其他應(yīng)用的資源，從而更好的為用戶服務(wù)。

OAuth 2.0 就是幫助用戶新型第三方應(yīng)用授權(quán)的協(xié)議，今天會(huì)給大家介紹 OAuth 2.0 的實(shí)現(xiàn)原理和協(xié)議授權(quán)規(guī)范。

包括如下內(nèi)容：

• 從簡(jiǎn)單的例子了解 OAuth
• OAuth 2.0 的定義和組成
• OAuth 2.0 的 Refresh Token
• OAuth 2.0 的授權(quán)模式

從簡(jiǎn)單的例子了解 OAuth

在介紹 OAuth 2.0 之前，讓我們來看一個(gè)簡(jiǎn)單的例子。假設(shè)你平時(shí)喜歡照相，將生活中的點(diǎn)點(diǎn)滴滴記錄成電子照片并且存放到云盤上，每隔一段時(shí)間會(huì)將心儀的照片挑選出來進(jìn)行打印保存。

同時(shí)你發(fā)現(xiàn)網(wǎng)絡(luò)上面有一個(gè)款云打印照片的應(yīng)用，只需要導(dǎo)入電子照片，這款應(yīng)用就可以幫你進(jìn)行打印然后將成片郵寄到你的家中。

我們將這個(gè)例子中的授權(quán)部分抽離出來形成圖 1 ，如圖 1 所示，左邊是云打印的部分，也就是我們需要使用的互聯(lián)網(wǎng)服務(wù)。右邊綠色的部分是用戶，也就是電子照片的資源擁有者。

圖 1：云打印服務(wù)的授權(quán)過程

針對(duì)云盤而言有兩個(gè)服務(wù)需要提供，一個(gè)是授權(quán)服務(wù)，也就是通過照片的所有者授權(quán)第三方應(yīng)用使用照片資源，另一個(gè)就是資源服務(wù)本身，也就是照片資源的提供者。

通過圖 1 的展示我們將整個(gè)請(qǐng)求云打印服務(wù)和授權(quán)的過程分為如下幾個(gè)步驟：

• 用戶請(qǐng)求云打印服務(wù)，此時(shí)運(yùn)用只是單純地請(qǐng)求服務(wù)，但是并沒有提供電子照片的資源給云打印服務(wù)。
• 云打印服務(wù)接收到請(qǐng)求以后，由于沒有電子照片云盤的訪問權(quán)限，于是請(qǐng)求用戶對(duì)云盤進(jìn)行授權(quán)。
• 用戶為了實(shí)現(xiàn)云打印服務(wù)，隨之授權(quán)云打印去訪問云盤中的電子照片。
• 云打印將用戶的授權(quán)告訴云盤中的授權(quán)服務(wù)。
• 授權(quán)服務(wù)得知用戶授權(quán)云打印服務(wù)可以打印用戶在云盤中的照片時(shí)，返回給云打印服務(wù)訪問權(quán)限。
• 拿到訪問照片資源權(quán)限的云打印服務(wù)，利用該訪問權(quán)限訪問云盤上面的電子照片資源。
• 云盤上的資源服務(wù)接收到待訪問權(quán)限的請(qǐng)求之后，返回電子照片，隨后云打印服務(wù)開始打印服務(wù)。

OAuth 2.0 的定義和組成

從上面這個(gè)小例子可以發(fā)現(xiàn)當(dāng)用戶訪問第三方的網(wǎng)絡(luò)應(yīng)用(云打印)的時(shí)候，需要通過授權(quán)的方式讓云打印具備訪問云盤資源的權(quán)限。

授權(quán)過后云盤的授權(quán)服務(wù)會(huì)返回給云打印應(yīng)有的權(quán)限，注意這里并沒有返回給云打印所有云盤權(quán)限。

例如：添加、刪除、修改電子照片，只是根據(jù)用戶的授權(quán)給了云打印部分的權(quán)限，也就是獲取電子照片的權(quán)限。

為什么要經(jīng)過這個(gè)授權(quán)的過程能，可以對(duì)其做如下分析：

• 如果為了打印照片，用戶將訪問云盤的用戶名密碼都交給云打印服務(wù)顯然不太安全。
• 云打印在獲得用戶云盤授權(quán)的時(shí)候并不是獲取所有的權(quán)限，而是獲取部分權(quán)限，這個(gè)權(quán)限只是能夠訪問電子照片而已，而且通常而言還可以設(shè)置該權(quán)限的訪問時(shí)長(zhǎng)，例如：2 小時(shí)或者 1 天，從而保證打印服務(wù)的正常進(jìn)行。
• 如果此時(shí)云打印通過得知用戶名和密碼的方式訪問云盤，那么云打印的系統(tǒng)被黑，就會(huì)導(dǎo)致云盤的資源被泄漏。

鑒于上面三點(diǎn)的分析，我們需要使用 OAuth 的方式進(jìn)行授權(quán)。OAuth 認(rèn)證是為了做到第三方應(yīng)用在未獲取到用戶敏感信息(如：賬號(hào)密碼、用戶 PIN 等)的情況下，能讓用戶授權(quán)予它來訪問開放平臺(tái)中的資源接口。

之所以使用 OAuth 2.0，是因?yàn)?OAuth 1.0 協(xié)議太復(fù)雜、易用性差較難普及。OAuth 2.0 通過新的協(xié)議設(shè)計(jì)，使用更加簡(jiǎn)單，更加容易普及。

在對(duì) OAuth 2.0 協(xié)議的設(shè)計(jì)目的了解之后，再來看看它的組成部分。把上面一節(jié)中提到的例子進(jìn)行映射可以將其分為 4 個(gè)組成部分。

圖 2：OAuth 2.0 執(zhí)行流程

如圖 2 所示：

• Client：作為訪問應(yīng)用的客戶端，也就是需要經(jīng)過授權(quán)才能訪問資源的應(yīng)用程序，在例子中就是第三方應(yīng)用(云打印)。
• Resource Owner：即資源所有者，例子中的用戶，他可以授予第三方應(yīng)用(云打印)也就是 Client，對(duì)受保護(hù)資源的訪問權(quán)限的實(shí)體。
• Authorization Server：即授權(quán)服務(wù)器，其作用是在 Resource Owner 驗(yàn)證并給予 Client 授權(quán)后，通過 Authorization Server 向 Client 頒發(fā)訪問的令牌。
• Resource Server：即資源服務(wù)器，它是用來存放資源的，在例子中用來存放電子照片，當(dāng) Client 使用令牌訪問它的時(shí)候，它會(huì)接受響應(yīng)并返回 Resource Owner 所保護(hù)的資源，也就是電子照片。

其中 Authorization Server 和 Resource Server 可以分開，也可能存在同一個(gè)服務(wù)器上面。按照上面的例子，這兩部分都屬于云盤服務(wù)器。

上面介紹了 OAuth 2.0 的幾個(gè)組件，這里再將圖 2 中的執(zhí)行流程給大家進(jìn)行講解：

• 客戶端(Client)向資源所有者(Resource Owner)請(qǐng)求授權(quán)。
• 客戶端(Client)收到用戶授權(quán)，這是代表資源所有者(Resource Owner)授權(quán)的憑證(Authorization)。
• 客戶端(Client)通過與授權(quán)服務(wù)器(Authorization Server)進(jìn)行身份驗(yàn)證并提供授權(quán)許可來請(qǐng)求訪問令牌(Access Token)。
• 授權(quán)服務(wù)器(Authorization Server)對(duì)客戶端進(jìn)行身份驗(yàn)證并驗(yàn)證授權(quán)許可，如果有效，則頒發(fā)訪問令牌(Access Token)。
• 客戶端(Client)從資源服務(wù)器(Resource Server)請(qǐng)求受保護(hù)的資源并通過提供訪問令牌(Access Token)進(jìn)行身份驗(yàn)證。
• 資源服務(wù)器(Resource Server)驗(yàn)證訪問令牌(Access Token)，如果有效，則為請(qǐng)求提供服務(wù)。

通過上面的流程 Client 終于可以拿到 Resource Server 上的資源為 Resource Owner 提供對(duì)應(yīng)的服務(wù)了。

這整個(gè)過程稱為授權(quán)許可，它代表資源的憑證所有者(Resource Owner)授權(quán)給客戶端(Client)訪問其受保護(hù)的資源，以及客戶端獲取訪問令牌的整個(gè)過程。

OAuth 2.0 的 Refresh Token

上面說道資源服務(wù)器(Resource Server)是通過驗(yàn)證客戶端(Client)的訪問令牌(Access Token)來提供資源服務(wù)的，因此訪問令牌(Access Token)就是訪問受保護(hù)資源的憑據(jù)。

它是一個(gè)字符串，并由授權(quán)服務(wù)器(Authorization Server)頒發(fā)客戶端(Client)的，同時(shí)會(huì)指定資源訪問范圍和持續(xù)時(shí)間。

正因?yàn)槿绱嗽L問令牌(Access Token)在超出范圍，特別是超出訪問時(shí)間的時(shí)候會(huì)出現(xiàn)失效的情況，此時(shí)客戶端就需要獲得額外的訪問令牌(Access Token)。

此時(shí)授權(quán)服務(wù)器會(huì)給客戶端發(fā)出刷新令牌(Refresh Token)，與訪問令牌(Access Token)不同的是刷新令牌(Refresh Token)僅用于授權(quán)服務(wù)器，從不發(fā)送 到資源服務(wù)器。

在后面會(huì)提到的授權(quán)碼模式中，授權(quán)服務(wù)器會(huì)同時(shí)返回刷新令牌(Refresh Token)。

其目的是在訪問令牌( Access Token)過期前，重新獲取新的訪問令牌(Access Token)，不需要資源所有者(Resource Owner)重新確認(rèn)授權(quán)，提高了授權(quán)效率和用戶體驗(yàn)。

在訪問令牌( Access Token) 前， 客戶端(Client)可用刷新令牌(Refresh Token)向授權(quán)服務(wù)器(Authorization Server)發(fā)送請(qǐng)求。

圖 3

如圖 3 所示，假設(shè) b.com 是授權(quán)服務(wù)器(Authorization Server)地址，請(qǐng)求包含如下內(nèi)容：

收到 grant_type：授權(quán)類型，值為 ‘refresh_token’。

client_id：客戶端 id，即客戶端(Client)在授權(quán)服務(wù)器上注冊(cè)被分配的 id。

client_secret：客戶端(Client)和授權(quán)服務(wù)器(Authorization Server)通行的密鑰，由授權(quán)服務(wù)器頒發(fā)，在特殊需要確認(rèn)的情況下需要作為驗(yàn)證條件。

refresh_token：用戶獲取新的 access_token 的 refresh_token。

OAuth 2.0 的授權(quán)模式

前面給大家介紹了 OAuth 2.0 的定義和組成結(jié)構(gòu)，并且詳細(xì)描述了其授權(quán)的流程，并且提出了 Access Token 過期情況下 Refresh Token 的解決方案。

接下來介紹 OAuth 2.0 的授權(quán)模式，也就是資源所有者將資源的使用權(quán)限授予給客戶端的方式。

這里列舉 4 種授權(quán)模式，分別是：

• 授權(quán)碼模式
• 隱含授權(quán)模式
• 密碼模式
• 客戶端模式

①授權(quán)碼模式(Authorization Code)

它是功能最完整、流程最嚴(yán)密的授權(quán)模式，其特點(diǎn)就是通過客戶端的后臺(tái)服務(wù)器，與"服務(wù)提供商"的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。

授權(quán)碼模式會(huì)使用兩種訪問權(quán)限令牌(Access Token)和刷新令牌(Refresh Token)，授權(quán)過程基于重定向的流。

客戶端(Client)能夠從資源所有者(Resource Owner)的用戶代理(User Agent)接收傳入的請(qǐng)求。

然后通過重定 URI 發(fā)送給授權(quán)服務(wù)器(Authorization Server)，并獲取返回的訪問令牌(Access Token)。

圖 4：授權(quán)碼模式流程圖

如圖 4 所示，這里將授權(quán)碼模式的流程處理分為 5 個(gè)步驟：

• 客戶端(Client)初始化流程，將資源所有者對(duì)應(yīng)的用戶代理(User Agent 瀏覽器)指向授權(quán)服務(wù)器(Authorization Server)。

此時(shí)客戶端(Client)包含了本身的 ID、請(qǐng)求范圍、本地狀態(tài)以及重定向的URI的信息。這個(gè) URI 是告訴授權(quán)服務(wù)器(Authorization Server)在授權(quán)完成之后回調(diào)用戶代理的 URI。

• 用戶代理(User Agent)會(huì)發(fā)送給授權(quán)服務(wù)器(Authorization Server)用戶的身份信息。

授權(quán)服務(wù)器(Authorization Server)會(huì)對(duì)資源所有者(Resource Owner)的身份進(jìn)行認(rèn)證，然后返回是否授權(quán)的結(jié)果。

• 假設(shè)授權(quán)服務(wù)器(Authorization Server)通過了資源所有者的授權(quán)，它將授權(quán)碼(Authorization Code)以及一些狀態(tài)信息通過重定向URI通過用戶代理返回給客戶端(Client)。
• 客戶端收到授權(quán)碼(Authorization Code)，附上重定向的URI向授權(quán)服務(wù)器(Authorization Server)申請(qǐng)?jiān)L問令牌(Access Token)。

同時(shí)也會(huì)附上重定向的 URI，當(dāng)返回訪問令牌(Access Token)的時(shí)候能夠找到對(duì)應(yīng)的客戶端(Client)。

• 認(rèn)證服務(wù)器(Authorization Server)核對(duì)了授權(quán)碼(Authorization Code)確認(rèn)無誤后，通過重定向的URI向客戶端發(fā)送訪問令牌(Access Token)和更新令牌(Refresh Token)。

后面的過程就是客戶端使用訪問令牌(Access Token)訪問資源服務(wù)器(Resource Server)了。

通過上面對(duì)授權(quán)碼模式的介紹，我們不僅會(huì)提出一個(gè)問題，客戶端為什么要獲取授權(quán)服務(wù)器中的授權(quán)嗎?

再用這個(gè)授權(quán)碼向授權(quán)服務(wù)器申請(qǐng)獲取訪問令牌，授權(quán)服務(wù)器直接把訪問令牌發(fā)給客戶端不久完了嗎，非要繞著么大一圈不是多次一舉嗎?

這里對(duì)這一原因進(jìn)行解釋如下：用戶代理在顯示中都以瀏覽器的方式存在，而瀏覽器中對(duì)應(yīng)的重定向 URI(redirect_uri)被認(rèn)為是不安全信道，此方式不適合敏感數(shù)據(jù)-訪問令牌的傳輸。

因?yàn)?URI 有可能通過 HTTP referrer 傳遞到其它惡意站點(diǎn)，也可能存在于瀏覽器 cacher 或 log 文件中，這就給攻擊者盜取訪問令牌提供了便利。

這里還有一個(gè)假設(shè)，就是設(shè)資源所有者的行為雖然是可信賴的，但是資源所有者所使用的用戶代理，也就是瀏覽器可能早已被攻擊者植入了跨站腳本用來監(jiān)聽訪問令牌。

此時(shí)將訪問令牌用戶代理傳遞給客戶端，會(huì)擴(kuò)大訪問令牌被泄露的風(fēng)險(xiǎn)。但授權(quán)碼(Authorization Code)是可以通過重定向 URI 來傳遞的。

授權(quán)碼并不像訪問令牌那樣敏感，即使授權(quán)碼泄露了，攻擊者也無法直接拿到訪問令牌從而訪問資源。因?yàn)槟玫绞跈?quán)碼去交換訪問令牌時(shí)是需要驗(yàn)證客戶端真實(shí)身份的。

說白了就是除了客戶端之外，其他人拿授權(quán)碼事沒有用的。這也事為什么訪問令牌只能發(fā)給客戶端使用的原因，其他任何主體包括資源所有者都不應(yīng)該獲取訪問令牌。

協(xié)議的設(shè)計(jì)保證客戶端是唯一有能力獲取訪問令牌的主體。引入授權(quán)碼的目的也是為了保證客戶端是訪問令牌的唯一持有人。

另外，由于協(xié)議需要驗(yàn)證客戶端的身份，如果不引入授權(quán)碼，客戶端的身份認(rèn)證只能通過重定向 URI 來傳遞。

由于重定向 URI 是一個(gè)不安全信道，就額外要求客戶端必須使用數(shù)字簽名技術(shù)來進(jìn)行身份認(rèn)證，而不能用簡(jiǎn)單的密碼或口令認(rèn)證方式。

引入授權(quán)碼之后，授權(quán)服務(wù)器可以直接對(duì)客戶端進(jìn)行身份認(rèn)證，可以支持任意的客戶端認(rèn)證方式。

可以理解為授權(quán)碼作為客戶端和資源所有者之間的中介，用來驗(yàn)證客戶端的身份。

②隱式授權(quán)模式(Implicit Grant )

它是一種簡(jiǎn)化模式，由于前面一種模式需要通過授權(quán)碼換取訪問令牌的方式實(shí)現(xiàn)授權(quán)，在提升安全性的同時(shí)增加了復(fù)雜度。

因此隱式授權(quán)模式會(huì)直接在用戶代理(瀏覽器)中向授權(quán)服務(wù)器申請(qǐng)?jiān)L問令牌，跳過了授權(quán)碼這個(gè)步驟，所有步驟在瀏覽器中完成，訪問令牌對(duì)訪問者是可見的，且客戶端不需要認(rèn)證。

圖 5：隱式授權(quán)模式流程圖

如圖 5 所示，我們一起來看看隱式授權(quán)模式的執(zhí)行流程：

• 客戶端(Client)初始化流程，將資源所有者對(duì)應(yīng)的用戶代理(User Agent 瀏覽器)指向授權(quán)服務(wù)器(Authorization Server)。
• 此時(shí)客戶端(Client)包含了本身的 ID、請(qǐng)求范圍、本地狀態(tài)以及重定向的URI的信息。這個(gè) URI 是告訴授權(quán)服務(wù)器(Authorization Server)在授權(quán)完成之后回調(diào)用戶代理的 URI。
• 用戶代理(User Agent)會(huì)發(fā)送給授權(quán)服務(wù)器(Authorization Server)用戶的身份信息，授權(quán)服務(wù)器(Authorization Server)會(huì)對(duì)資源所有者(Resource Owner)的身份進(jìn)行認(rèn)證，然后返回是否授權(quán)的結(jié)果。
• 假設(shè)授權(quán)服務(wù)器(Authorization Server)通過了資源所有者的授權(quán)，它將訪問令牌(訪問令牌)使用重定向 URI 通過用戶代理返回給客戶端(Client)。
• 用戶代理(User Agent)通過重定向的 URI 被指向到 Web 所托管的客戶端資源上。
• Web 所托管的客戶端資源會(huì)返回一個(gè) Web 頁面，該頁面是一個(gè)帶有 Script 腳本的 HTML 文檔，其中包含可以訪問所有資源的訪問令牌(Access Token)。
• 用戶代理(User Agent)也就是瀏覽器，在接收到返回的 Script 以后，從中抽取需要的訪問令牌(Access Token)。
• 隨后用戶代理(User Agent)將訪問令牌(Access Token)傳給客戶端(Client)，繼續(xù)后續(xù)的資源獲取工作。

正如前面提到的隱式授權(quán)模式簡(jiǎn)化了授權(quán)碼獲取的過程，通過 Web 托管客戶資源返回的 Script 腳本中攜帶了對(duì)應(yīng)的訪問碼，用戶代理在抽取訪問碼之后返回給客戶端調(diào)用資源。

這種方式雖然省去了獲取授權(quán)碼的過程，但是在用戶代理中存放了訪問碼存在一定的安全風(fēng)險(xiǎn)。

③密碼模式(Resource Owner Password Credentials Grant)

用戶向客戶端提供自己的用戶名和密碼?？蛻舳耸褂眠@些信息，向授權(quán)服務(wù)器索要授權(quán)。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲(chǔ)存密碼。

這通常用在用戶對(duì)客戶端高度信任的前提下才能進(jìn)行，比如客戶端是操作系統(tǒng)的一部分，或者由一個(gè)著名公司出品。而認(rèn)證服務(wù)器只有在其他授權(quán)模式無法執(zhí)行的情況下，才能考慮使用這種模式。

圖 6：密碼模式流程圖

接下來我們一起看看密碼模式的執(zhí)行流程，如圖 6 所示，整個(gè)過程比較簡(jiǎn)單分為 3 個(gè)步驟：

• 資源所有者向客戶端提供用戶名和密碼
• 客戶端將從資源所有者處獲取的授權(quán)(用戶名+密碼)發(fā)送給授權(quán)服務(wù)器，從而獲取訪問資源服務(wù)器的權(quán)限。
• 授權(quán)服務(wù)器確認(rèn)資源所有者的授權(quán)(用戶名+密碼)之后返回訪問令牌以及刷新令牌。

④客戶端模式(Client Credentials Grant)

指客戶端以自己的名義，而不是以用戶的名義，向授權(quán)服務(wù)器進(jìn)行認(rèn)證。在這種模式中，用戶直接向客戶端注冊(cè)，客戶端以自己的名義要求授權(quán)服務(wù)器提供服務(wù)，不存在授權(quán)問題。

由于不存在資源所有者的授權(quán)行為，因此這種模式嚴(yán)格上來說不屬于 OAuth 2.0 的模式范疇?？蛻舳嗽谑跈?quán)服務(wù)器上存在可控資源的情況，才能使用這種方式。

圖 7：客戶端模式流程圖

如圖 7 所示，這種模式分為 2 步：

• 客戶端自身向授權(quán)服務(wù)器發(fā)起授權(quán)請(qǐng)求，申請(qǐng)獲取訪問令牌。
• 授權(quán)服務(wù)器在經(jīng)過認(rèn)證授權(quán)以后發(fā)送給客戶端訪問令牌。

總結(jié)

本文從云打印照片的例子開始，通過用戶授權(quán)云打印服務(wù)訪問云盤獲取電子照片的整個(gè)過程，帶出了 OAuth 2.0 所實(shí)現(xiàn)的資源授權(quán)與訪問的功能。

然后提出 OAuth 2.0 是用來保證第三方應(yīng)用授權(quán)訪問資源安全性的協(xié)議，其協(xié)議會(huì)涉及到客戶端、資源所有者、授權(quán)服務(wù)器和資源服務(wù)器，并且描述了授權(quán)過程如何在它們之間展開的。

在介紹完授權(quán)流程之后，又進(jìn)一步說明了在過程中獲取訪問令牌才能訪問資源，如果令牌過期的情況下需要通過刷新令牌保持授權(quán)的有效性。 

最后介紹了 OAuth 2.0 的 4 種授權(quán)模式，分別是授權(quán)碼模式、隱含授權(quán)模式、密碼模式和客戶端模式，以及它們的實(shí)現(xiàn)流程。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】