【51CTO.com原創稿件】在互聯網蓬勃發展的今天，互聯網應用層出不窮，每個應用專注的領域和方法也不相同。

[[435855]]

圖片來自 包圖網

為了給用戶更好的使用體驗，一個互聯網應用會請求用戶授權獲取另外一個應用，在獲取授權之后就可以獲取其他應用的資源，從而更好的為用戶服務。

OAuth 2.0 就是幫助用戶新型第三方應用授權的協議，今天會給大家介紹 OAuth 2.0 的實現原理和協議授權規范。

包括如下內容：

• 從簡單的例子了解 OAuth
• OAuth 2.0 的定義和組成
• OAuth 2.0 的 Refresh Token
• OAuth 2.0 的授權模式

從簡單的例子了解 OAuth

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

同時你發現網絡上面有一個款云打印照片的應用，只需要導入電子照片，這款應用就可以幫你進行打印然后將成片郵寄到你的家中。

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

圖 1：云打印服務的授權過程

針對云盤而言有兩個服務需要提供，一個是授權服務，也就是通過照片的所有者授權第三方應用使用照片資源，另一個就是資源服務本身，也就是照片資源的提供者。

通過圖 1 的展示我們將整個請求云打印服務和授權的過程分為如下幾個步驟：

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

OAuth 2.0 的定義和組成

從上面這個小例子可以發現當用戶訪問第三方的網絡應用(云打印)的時候，需要通過授權的方式讓云打印具備訪問云盤資源的權限。

授權過后云盤的授權服務會返回給云打印應有的權限，注意這里并沒有返回給云打印所有云盤權限。

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

為什么要經過這個授權的過程能，可以對其做如下分析：

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

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

之所以使用 OAuth 2.0，是因為 OAuth 1.0 協議太復雜、易用性差較難普及。OAuth 2.0 通過新的協議設計，使用更加簡單，更加容易普及。

在對 OAuth 2.0 協議的設計目的了解之后，再來看看它的組成部分。把上面一節中提到的例子進行映射可以將其分為 4 個組成部分。

圖 2：OAuth 2.0 執行流程

如圖 2 所示：

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

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

上面介紹了 OAuth 2.0 的幾個組件，這里再將圖 2 中的執行流程給大家進行講解：

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

通過上面的流程 Client 終于可以拿到 Resource Server 上的資源為 Resource Owner 提供對應的服務了。

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

OAuth 2.0 的 Refresh Token

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

它是一個字符串，并由授權服務器(Authorization Server)頒發客戶端(Client)的，同時會指定資源訪問范圍和持續時間。

正因為如此訪問令牌(Access Token)在超出范圍，特別是超出訪問時間的時候會出現失效的情況，此時客戶端就需要獲得額外的訪問令牌(Access Token)。

此時授權服務器會給客戶端發出刷新令牌(Refresh Token)，與訪問令牌(Access Token)不同的是刷新令牌(Refresh Token)僅用于授權服務器，從不發送 到資源服務器。

在后面會提到的授權碼模式中，授權服務器會同時返回刷新令牌(Refresh Token)。

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

在訪問令牌( Access Token) 前， 客戶端(Client)可用刷新令牌(Refresh Token)向授權服務器(Authorization Server)發送請求。

圖 3

如圖 3 所示，假設 b.com 是授權服務器(Authorization Server)地址，請求包含如下內容：

收到 grant_type：授權類型，值為 ‘refresh_token’。

client_id：客戶端 id，即客戶端(Client)在授權服務器上注冊被分配的 id。

client_secret：客戶端(Client)和授權服務器(Authorization Server)通行的密鑰，由授權服務器頒發，在特殊需要確認的情況下需要作為驗證條件。

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

OAuth 2.0 的授權模式

前面給大家介紹了 OAuth 2.0 的定義和組成結構，并且詳細描述了其授權的流程，并且提出了 Access Token 過期情況下 Refresh Token 的解決方案。

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

這里列舉 4 種授權模式，分別是：

• 授權碼模式
• 隱含授權模式
• 密碼模式
• 客戶端模式

①授權碼模式(Authorization Code)

它是功能最完整、流程最嚴密的授權模式，其特點就是通過客戶端的后臺服務器，與"服務提供商"的認證服務器進行互動。

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

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

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

圖 4：授權碼模式流程圖

如圖 4 所示，這里將授權碼模式的流程處理分為 5 個步驟：

• 客戶端(Client)初始化流程，將資源所有者對應的用戶代理(User Agent 瀏覽器)指向授權服務器(Authorization Server)。

此時客戶端(Client)包含了本身的 ID、請求范圍、本地狀態以及重定向的URI的信息。這個 URI 是告訴授權服務器(Authorization Server)在授權完成之后回調用戶代理的 URI。

• 用戶代理(User Agent)會發送給授權服務器(Authorization Server)用戶的身份信息。

授權服務器(Authorization Server)會對資源所有者(Resource Owner)的身份進行認證，然后返回是否授權的結果。

• 假設授權服務器(Authorization Server)通過了資源所有者的授權，它將授權碼(Authorization Code)以及一些狀態信息通過重定向URI通過用戶代理返回給客戶端(Client)。
• 客戶端收到授權碼(Authorization Code)，附上重定向的URI向授權服務器(Authorization Server)申請訪問令牌(Access Token)。

同時也會附上重定向的 URI，當返回訪問令牌(Access Token)的時候能夠找到對應的客戶端(Client)。

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

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

通過上面對授權碼模式的介紹，我們不僅會提出一個問題，客戶端為什么要獲取授權服務器中的授權嗎?

再用這個授權碼向授權服務器申請獲取訪問令牌，授權服務器直接把訪問令牌發給客戶端不久完了嗎，非要繞著么大一圈不是多次一舉嗎?

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

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

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

此時將訪問令牌用戶代理傳遞給客戶端，會擴大訪問令牌被泄露的風險。但授權碼(Authorization Code)是可以通過重定向 URI 來傳遞的。

授權碼并不像訪問令牌那樣敏感，即使授權碼泄露了，攻擊者也無法直接拿到訪問令牌從而訪問資源。因為拿到授權碼去交換訪問令牌時是需要驗證客戶端真實身份的。

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

協議的設計保證客戶端是唯一有能力獲取訪問令牌的主體。引入授權碼的目的也是為了保證客戶端是訪問令牌的唯一持有人。

另外，由于協議需要驗證客戶端的身份，如果不引入授權碼，客戶端的身份認證只能通過重定向 URI 來傳遞。

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

引入授權碼之后，授權服務器可以直接對客戶端進行身份認證，可以支持任意的客戶端認證方式。

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

②隱式授權模式(Implicit Grant )

它是一種簡化模式，由于前面一種模式需要通過授權碼換取訪問令牌的方式實現授權，在提升安全性的同時增加了復雜度。

因此隱式授權模式會直接在用戶代理(瀏覽器)中向授權服務器申請訪問令牌，跳過了授權碼這個步驟，所有步驟在瀏覽器中完成，訪問令牌對訪問者是可見的，且客戶端不需要認證。

圖 5：隱式授權模式流程圖

如圖 5 所示，我們一起來看看隱式授權模式的執行流程：

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

正如前面提到的隱式授權模式簡化了授權碼獲取的過程，通過 Web 托管客戶資源返回的 Script 腳本中攜帶了對應的訪問碼，用戶代理在抽取訪問碼之后返回給客戶端調用資源。

這種方式雖然省去了獲取授權碼的過程，但是在用戶代理中存放了訪問碼存在一定的安全風險。

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

用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向授權服務器索要授權。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。

這通常用在用戶對客戶端高度信任的前提下才能進行，比如客戶端是操作系統的一部分，或者由一個著名公司出品。而認證服務器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。

圖 6：密碼模式流程圖

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

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

④客戶端模式(Client Credentials Grant)

指客戶端以自己的名義，而不是以用戶的名義，向授權服務器進行認證。在這種模式中，用戶直接向客戶端注冊，客戶端以自己的名義要求授權服務器提供服務，不存在授權問題。

由于不存在資源所有者的授權行為，因此這種模式嚴格上來說不屬于 OAuth 2.0 的模式范疇?？蛻舳嗽谑跈喾掌魃洗嬖诳煽刭Y源的情況，才能使用這種方式。

圖 7：客戶端模式流程圖

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

• 客戶端自身向授權服務器發起授權請求，申請獲取訪問令牌。
• 授權服務器在經過認證授權以后發送給客戶端訪問令牌。

總結

本文從云打印照片的例子開始，通過用戶授權云打印服務訪問云盤獲取電子照片的整個過程，帶出了 OAuth 2.0 所實現的資源授權與訪問的功能。

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

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

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

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】