附錄B OAuth2受權類型

    本附錄主要內容

    OAuth2密碼受權（password grant）

    OAuth2客戶端憑據受權（client credentials grant）

    OAuth2鑑權碼受權（authorization code grant）

    OAuth2隱式受權（implicit grant）

    OAuth2令牌刷新

 

在閱讀第7章時，讀者可能會認爲OAuth2看起來不太複雜。畢竟有一個驗證服務，用於檢查用戶的憑據並頒發令牌給用戶。每次用戶想要調用由OAuth2服務器保護的服務時，均可以依次出示令牌。

    遺憾的是，現實世界歷來都不是簡單的。因爲Web應用程序和基於雲的應用程序具備相互關聯的性質，用戶指望能夠安全地共享本身的數據，並在不一樣服務所擁有的不一樣應用程序之間整合功能。這從安全角度來看，是一個獨特的挑戰，由於開發人員但願跨不一樣的應用程序進行整合，而不是強迫用戶與他們想要集成的每一個應用程序共享他們的憑據。

    幸運的是，OAuth2是一個靈活的受權框架，它爲應用程序提供了多種機制來對用戶進行驗證和受權，而不用強制他們共享憑據。可是，這也是OAuth2被認爲是複雜的緣由之一。這些驗證機制被稱爲驗證受權（authentication grant）。OAuth2有4種模式的驗證受權，客戶端應用程序可使用它們來對用戶進行驗證、接收訪問令牌，而後確認該令牌。這些受權分別是：

    密碼受權；

    客戶端憑據受權；

    受權碼受權；

    隱式受權。

    在下面幾節中，我將介紹在執行每一個OAuth2受權流程期間發生的活動，同時我會談到什麼時候適合使用何用受權類型。

 

B.1　密碼受權

    OAuth2密碼受權多是最容易理解的受權類型。這種受權類型適用於應用程序和服務都明確相互信任的時候。例如，EagleEye Web應用程序和EagleEye Web服務（許可證服務和組織服務）都由ThoughtMechanix擁有，因此它們之間存在着一種自然的信任關係。

    注意

    

    明確地說，當我提到「自然的信任關係」時，個人意思是應用程序和服務徹底由同一個組織擁有，而且它們是按照相同的策略和程序來管理的。

    當存在一種自然的信任關係時，幾乎不用擔憂將OAuth2訪問令牌暴露給調用應用程序。例如，EagleEye Web應用程序可使用OAuth2密碼受權來捕獲用戶憑據，並直接針對EagleEye OAuth2服務進行驗證。圖B-1展現了EagleEye和下游服務之間的密碼受權。

 

圖B-1　OAuth2服務肯定訪問服務的用戶是否爲已經過驗證的用戶

    在圖B-1中，正在發生如下活動。

    （1）在EagleEye應用程序可使用受保護資源以前，它須要在OAuth2服務中被惟一標識。一般，應用程序的全部者經過OAuth2服務進行註冊，併爲其應用程序提供惟一的名稱。OAuth2服務隨後提供一個密鑰給正在註冊的應用程序。

    應用程序的名稱和由OAuth2服務提供的密鑰惟一地標識了試圖訪問任何受保護資源的應用程序。

    （2）用戶登陸到EagleEye，並將其登陸憑據提供給EagleEye應用程序。EagleEye將用戶憑據以及應用程序名稱、應用程序密鑰直接傳給EagleEye OAuth2服務。

    （3）EagleEye OAuth2服務對應用程序和用戶進行驗證，而後向用戶提供OAuth2訪問令牌。

    （4）每次EagleEye應用程序表明用戶調用服務時，它都會傳遞OAuth2服務器提供的訪問令牌。

    （5）當一個受保護的服務（在本例中是許可證服務和組織服務）被調用時，該服務將回調到EagleEye OAuth2服務來確認令牌。若是令牌是有效的，則被調用的服務容許用戶繼續進行操做。若是令牌無效，OAuth2服務將返回HTTP狀態碼403，指示該令牌無效。

 

B.2　客戶端憑據受權

    當應用程序須要訪問受OAuth2保護的資源時，一般會使用客戶端憑據受權，但在這個事務中不涉及任何人員。使用客戶端憑據受權類型，OAuth2服務器僅根據應用程序名稱和資源全部者提供的密鑰進行驗證。一樣，客戶端憑據受權常常用於兩個應用程序都歸同一個公司全部時。密碼受權和客戶端憑據受權的區別在於，客戶端憑據受權僅使用註冊的應用程序名稱和密鑰進行驗證。

    例如，假設EagleEye應用程序每隔一小時就會運行一個數據分析做業。做爲其工做的一部分，它向EagleEye服務發出調用。可是，EagleEye開發人員仍然但願應用程序在訪問這些服務中的數據以前，進行驗證和鑑權。這是可使用客戶端憑據受權的場景。圖B-2展現了這個流程。

 

但願應用程序在訪問這些服務中的數據以前，進行驗證和鑑權。這是可使用客戶端憑據受權的場景。圖B-2展現了這個流程。

 

圖B-2　客戶端憑據受權適用於「無用戶參與」的應用程序驗證和受權

    （1）資源全部者經過OAuth2服務註冊了EagleEye數據分析應用程序。資源全部者將提供應用程序的名稱並接收一個密鑰。

    （2）當EagleEye數據分析做業運行時，它將出示應用程序名稱和資源全部者提供的密鑰。

    （3）EagleEye OAuth2服務將使用提供的應用程序名稱和密鑰對應用程序進行驗證，而後返回一個OAuth2訪問令牌。

    （4）每當應用程序調用EagleEye服務時，它就會出示它在OAuth2服務調用中接收到的OAuth2訪問令牌。

 

B.3　鑑權碼受權

    受權碼受權是迄今爲止最複雜的OAuth2受權，但它也是最經常使用的流程，由於它容許來自不一樣供應商的不一樣應用程序共享數據和服務，而無須在多個應用程序間暴露用戶憑據。鑑權碼受權不會讓調用應用程序當即得到OAuth2訪問令牌，而是使用一個「預訪問」受權碼的方式來執行額外的檢查。

    理解受權碼受權的簡單方法就是看一個例子。假設有一個EagleEye用戶，它也使用 Salesforce.com。EagleEye客戶的IT部門已經構建了一個Salesforce應用程序，它須要EagleEye服務（組織服務）的數據。來看一下圖B-3，看看受權碼受權是如何使Salesforce從EagleEye的組織服務中訪問數據而無須EagleEye客戶向Salesforce公開他們的EagleEye憑據的。

圖B-3　受權碼受權可讓應用程序在不暴露用戶憑據的狀況下共享數據

    （1）EagleEye用戶登陸到EagleEye，併爲其Salesforce應用程序生成應用程序名稱和應用程序密鑰。做爲註冊過程的一部分，還將提供一個回調URL，以返回到基於Salesforce的應用程序。此回調URL是一個Salesforce的URL，將在EagleEye OAuth2服務器驗證了用戶的EagleEye憑據後被調用。

 

（2）用戶使用如下信息配置Salesforce應用程序：

    爲Salesforce建立的應用程序名稱；

    爲Salesforce生成的密鑰；

    指向EagleEye OAuth2登陸頁面的URL。

    如今，當用戶嘗試使用Salesforce應用程序並經過組織服務訪問EagleEye數據時，根據上述要點中描述的URL，用戶將被重定向到EagleEye登陸頁面。用戶將提供他們的EagleEye憑據。若是提供的EagleEye憑據有效，則EagleEye OAuth2服務器將生成一個受權碼，並經過步驟1中提供的URL將用戶重定向到Salesforce。受權碼將做爲回調URL的一個查詢參數被髮送。

    （3）自定義的Salesforce應用程序將對受權碼進行持久化。注意，此受權碼不是OAuth2訪問令牌。

    （4）一旦存儲了受權碼，自定義的Salesforce應用程序就能夠向Salesforce應用程序出示在註冊過程當中生成的密鑰，並將受權碼返回給EagleEye OAuth2服務器。EagleEye OAuth2服務器將確認受權碼是否有效，而後將OAuth2令牌返回給自定義的Salesforce應用程序。每次自定義的Salesforce應用程序須要對用戶進行驗證並獲取OAuth2訪問令牌時，都會使用此受權碼。

（5）Salesforce應用程序將在HTTP首部中傳遞OAuth2令牌以調用EagleEye組織服務。

    （6）組織服務將經過EagleEye OAuth2服務來確認傳入EagleEye服務調用的OAuth2訪問令牌。若是令牌有效，組織服務將處理用戶的請求。

    這真的太使人激動了！應用程序到應用程序的集成是錯綜複雜的。這整個流程中要注意的是，即便用戶登陸到Salesforce而且正在訪問EagleEye數據，用戶的EagleEye憑據也不會直接暴露給Salesforce。在EagleEye OAuth2服務生成並提供初始受權碼以後，用戶就不再用向EagleEye服務提供他們的憑據了。

    B.4　隱式受權

    受權碼模式能夠在經過傳統的服務器端Web編程環境（如Java或.NET）運行Web應用程序時使用。若是客戶端應用程序是純JavaScript應用程序或徹底在Web瀏覽器中運行的移動應用程序，而且不依靠服務器端調用來調用第三方服務，那麼會發生什麼呢？

    這就是最後一種受權類型，即隱式受權，可以發揮做用的地方。圖B-4展現了在隱式受權中發生的通常流程。

 

圖B-4　隱式受權用於基於瀏覽器的單頁面應用程序（Single-Page Application，SPA） JavaScript應用程序

    

隱式受權一般用於處理徹底在瀏覽器內運行的純JavaScript應用程序。在其餘受權流程中，客戶端與執行用戶請求的應用程序服務器（客戶端應用程序-已經註冊了）進行通訊，而後應用程序服務器與下游服務進行交互。使用隱式受權類型，全部的服務交互都直接從用戶的客戶端（一般是Web瀏覽器）發生。在圖B-4中，正在進行如下活動：

 

    （1）JavaScript應用程序的全部者已經經過EagleEye OAuth2服務器註冊了應用程序。他們提供了一個應用程序名稱以及一個回調URL，該URL將被重定向並帶有用戶的OAuth2訪問令牌。

    （2）JavaScript應用程序將調用OAuth2服務。JavaScript應用程序必須出示預註冊的應用程序名稱。OAuth2服務器將強制用戶進行驗證。

    （3）若是用戶成功進行了驗證，那麼EagleEye OAuth2服務將不會返回一個令牌，而是將用戶重定向回一個頁面，該頁面是JavaScript應用程序全部者在第一步中註冊的頁面。在重定向回的URL中，OAuth2訪問令牌將被OAuth2驗證服務做爲查詢參數傳遞。

    （4）應用程序將接收傳入的請求並運行JavaScript腳本，該腳本將解析OAuth2訪問令牌並將其存儲（一般做爲Cookie）。

    （5）每次調用受保護資源時，就會將OAuth2訪問令牌出示給調用服務。

    （6）調用服務將確認OAuth2令牌，並檢查用戶是否被受權執行他們正在嘗試的活動。

    關於OAuth2隱式受權，記住下面幾點。

    隱式受權是惟一一種OAuth2訪問令牌直接暴露給公共客戶端（Web瀏覽器）的受權類型。在受權碼受權中，客戶端應用程序得到一個返回到託管應用程序的應用程序服務器的受權碼。經過受權碼受權，用戶能夠經過出示受權碼來得到OAuth2訪問權限。返回的OAuth2令牌不會直接暴露給用戶的瀏覽器。在客戶端憑據受權中，受權發生在兩個基於服務器的應用程序之間。在密碼受權中，向服務發出請求的應用程序和這個服務都是可信的，而且屬於同一個組織。

    由隱式受權生成的 OAuth2 令牌更容易受到攻擊和濫用，由於令牌可供瀏覽器使用。在瀏覽器中運行的任何惡意JavaScript均可以訪問OAuth2訪問令牌，並以他人的名義調用他人爲了調用服務而檢索到的OAuth2令牌，實質上是在模擬他人。

    隱式受權類型的OAuth2令牌應該是短暫的（1～2小時）。由於OAuth2訪問令牌存儲在瀏覽器中，因此OAuth2規範（和Spring Cloud Security）不支持能夠自動更新令牌的刷新令牌的概念。

 

B.5　如何刷新令牌

    當OAuth2訪問令牌被頒發時，其有效時間是有限的，它最終會過時。當令牌到期時，調用應用程序（和用戶）將須要使用OAuth2服務從新進行驗證。可是，在大多數OAuth2受權流程中，OAuth2服務器將同時頒發訪問令牌和刷新令牌。客戶端能夠將刷新令牌出示給OAuth2驗證服務，該服務將確認刷新令牌，而後發出新的OAuth2訪問令牌。來看看圖B-5，查看一下刷新令牌流程。

 

圖B-5　刷新令牌可讓應用程序獲取新的訪問令牌而不強制用戶從新進行驗證

    （1）用戶已經登陸了EagleEye，而且早已經過EagleEye OAuth2服務進行了驗證。用戶正在愉快地工做，可是，他們的令牌已通過期了。

    （2）用戶下一次嘗試調用服務（如組織服務）時，EagleEye應用程序將把過時的令牌傳遞給組織服務。

    （3）組織服務將嘗試使用OAuth2服務確認令牌，OAuth2服務返回HTTP狀態碼401（未經受權）和一個JSON淨荷，指示該令牌再也不有效。組織服務將把HTTP狀態碼401返回給調用服務。

    （4）EagleEye應用程序收到HTTP狀態碼401和JSON淨荷，指出調用從組織服務失敗的緣由。EagleEye應用程序將使用刷新令牌調用OAuth2驗證服務。OAuth2驗證服務將確認刷新令牌，而後發回新的訪問令牌。