接口測試工具-Jmeter使用筆記（八：模擬OAuth2.0協議簡化模式的請求）
背景
博主的主要工作是測試API，目前已經用Jmeter+Jenkins實現了項目中的接口自動化測試流程。但是馬上要接手的項目，API應用的是OAuth2.0協議授權，並且采用的是簡化模式（implicit grant type）。所以最近學習了一下該協議，並嘗試用Jmeter模擬該授權方式的處理流程，以改進自動化測試腳本。
本文主要分為三個部分：1、簡述OAuth2.0協議中的簡化模式授權方式；
2、通過在瀏覽器上抓包，分析獲取授權的過程中經歷了什麽；
3、嘗試用Jmeter模擬整個授權過程，獲取授權令牌。
一、OAuth2.0協議簡述
OAuth 2.0定義了四種授權方式。博主這裏只介紹簡化模式。有興趣了解該協議全部內容的同學可以參考本文末的參考文章。
授權過程中參與的四種角色：
- 資源所有者（Resource Owner）：對資源具有授權能力的人。即用戶。
- 第三方應用（Client）：獲得資源所有者的授權後，就可以去訪問資源所有者的資源。
- 資源服務器（Resource Server）：存儲資源，並處理對資源的訪問請求。
- 授權服務器（Authorization Server）：它認證資源所有者的身份，為資源所有者提供授權審批流程，並最終頒發授權令牌(Access Token)。
請註意，為了便於協議的描述，這裏只是在邏輯上把授權服務器與資源服務器區分開來；在物理上，AS與RS的功能可以由同一個服務器來提供服務。
簡化模式的基本工作流程如下：用戶被請求授權應用程序，然後授權服務器將訪問令牌傳遞回用戶代理，用戶代理將其傳遞給應用程序。
Step 1: Implicit Authorization Link
使用簡化模式授權類型，用戶會得到一個授權鏈接，它會從API來請求獲取令牌（即：token）。授權鏈接如下所示：
http://10.10.28.141:9999/uaa/oauth/authorize?response_type=token&client_id=cmop&redirect_uri=http://example.com
對授權鏈接的各部分介紹：
-
http://10.10.28.141:9999/uaa/oauth/authorize：API授權端點
-
client_id=cmop：應用程序的客戶端ID（API用來標識應用程序）
-
redirect_uri=http://example.com：當令牌頒發之後，認證服務器把用戶導向客戶端指定的重定向URI
-
response_type=token：表示授權類型，固定值為token，表示請求授權令牌
Step 2: User Authorizes Application
當用戶點擊這個鏈接時，首先要登錄到服務器驗證身份（除非已經登錄過），然後服務器會提示用戶進行授權或拒絕第三方應用使用他們的賬戶。
Step 3: User-agent Receives Access Token with Redirect URI
如果用戶同意授權，授權服務器將用戶導向客戶端指定的“重定向URI”，並在其中攜帶一個包含訪問令牌的URI片段，看起來像這樣：
http://example.com/#access_token=b8c512ef-8083-4654-b71b-7bbe85b03d8d&token_type=bearer&expires_in=19062&scope=open
對重定向URI的各部分介紹：
-
access_token：表示訪問令牌
-
token_type：表示令牌類型，該值大小寫不敏感，必選項，可以是bearer類型或mac類型
-
expires_in：表示過期時間，單位為秒
-
scope：表示權限範圍
好了，後面提取令牌以及把令牌發回給應用程序的步驟就不展開了，我們只要了解到如何獲取到授權令牌就可以了，接下來訪問服務器資源的時候，在請求API的requests中帶入令牌參數即可。
二、瀏覽器抓包過程
1、在瀏覽器中使用授權鏈接發起申請令牌請求
http://10.10.28.141:9999/uaa/oauth/authorize?response_type=token&client_id=cmop&redirect_uri=http://example.com
（1）Firefox瀏覽器，打開Firebug，輸入授權鏈接發起請求，如下圖：
從圖上可看出，我發起請求後，抓到6條GET請求，前兩條是我們需要關註分析的數據，後面四條都是在請求頁面元素所以不做關註：
-
-
- 第一條請求：GET請求授權鏈接，返回狀態碼為302，表示請求鏈接被暫時性重定向；
- 第二條請求：GET請求暫時性重定向的鏈接，即跳轉到目前的頁面，其URL為http://10.10.28.141:9999/uaa/login.html
-
（2）接下來我們看一下前兩條requests中的具體信息，如下圖：
從圖上可以看出，發起第一個GET請求（即授權鏈接），在其響應頭信息（Response Headers）中的Location字段標明了接下來瀏覽器將重定向的地址；而且還在其中返回一個Set-Cookie字段；
再來看第二個請求，他的請求頭信息（Request Headers）中包含一個參數Cookie，該值與上面的Set-Cookie字段的值相同。
註意：我們把這裏的Set-Cookie和Cookie的值起個名字，叫做JSESSIONID_1，方便和後面的cookie值進行區分。
2、用戶同意進行授權操作
http://10.10.28.141:9999/uaa/login.html
（1）在前一步的操作中，我們進行到瀏覽器跳轉到暫時性重定向的頁面，等待用戶輸入賬號密碼驗證身份，然後進行授權。
我們首先輸入正確的用戶名密碼，通過驗證，查看瀏覽器會發出什麽請求：
從圖上可看出，我在輸入用戶名密碼後，抓到3條請求，並且瀏覽器跳轉到指定的重定向URI，而且可以在該鏈接中看到服務器返回來的access_token參數：
-
-
- 第一條請求：POST請求，向服務器提供用戶名密碼參數，服務器驗證用戶身份通過後，跳轉回申請授權鏈接；
- 第二條請求：GET請求，再次向服務器請求申請授權令牌（此時已經得到用戶的授權），服務器會頒發令牌，認證服務器把用戶導向客戶端指定的重定向URI；
- 第三條請求：GET請求，重定向的URI，並且其中包括訪問令牌access_token
-
（2）接下來我們看一下request中的具體信息：
-
-
- POST請求：請求頭信息中傳入的cookie參數，與第一個步驟中獲取的JSESSIONID_1值一模一樣。響應頭信息中返回的Set-Cookie值記錄為JSESSIONID_2；
- 第一個GET請求：再次跳轉到授權鏈接向服務器發起請求，此時請求頭信息中傳入的Cookie參數是JSESSIONID_2，響應頭信息中的Location字段包含令牌；
- 第二個GET請求：我沒有截他的圖，因為他只是最終認證服務器把用戶導向的重定向URI。而我們已經拿到token的數據了。
-
總結：從用戶在瀏覽器輸入授權鏈接到最後瀏覽器返回給我們access_token的過程中，由於其中包含暫時性重定向的地址，所以瀏覽器自動進行過很多跳轉。需要我註意的只有兩個請求，第一個是GET請求授權鏈接，瀏覽器會自動跳轉到用戶身份驗證頁面，並保存一個cookie（我叫它驗證cookie）；第二個就是POST請求用戶認證連接，傳入用戶名和密碼參數，並帶入驗證cookie，服務器驗證用戶身份後再返回另一個cookie（我叫它授權cookie），也保存在瀏覽器中，然後自動跳轉到授權鏈接，此時傳入授權cookie，服務器即頒發正確的令牌給用戶~~
三、Jmeter模擬獲取令牌
通過前兩部分的分析，我需要發送兩個請求即可。
GET http://10.10.28.141:9999/uaa/oauth/authorize?response_type=token&client_id=cmop&redirect_uri=http://example.com
POST http://10.10.28.141:9999/uaa/login.html
請求一：
請求二：
執行測試：
結果裏面會發現，第一個請求執行沒問題。但是第二個請求最後沒有重新跳轉回授權鏈接，更別提Response headers裏面會有服務器頒發的令牌了！！
問題肯定是出在第一個GET請求的cookie沒有傳入POST請求，我翻了翻Jmeter的官方文檔試圖找到什麽方法能夠傳遞cookie這個參數，很快我就找到一個跟cookie相關的配置元件----前方高能預警！！！！！
HTTP Cookie Manager（HTTP Cookie管理器）
長話短說，我把這部分的重點直接從官網翻譯過來如下：
——cookie管理器主要有兩個功能
- 它可以像瀏覽器一樣保存並發送cookies：如果你的http請求的響應中包含一個cookie，那麽Cookie Manager就會自動保存這些Cookie並在所有後續請求該站點的請求中使用這個Cookie的值。對Jmeter來說，每個線程都有自己的“cookie存儲區域”。（註意：這樣的cookie不會在Cookie Manager中展示給用戶，但是用戶可以使用監聽器“查看結果樹”來查看）
- 用戶可以手動添加cookie到Cookie Manager，這種方式添加的cookie會被Jmeter的所有線程共享。
從上面這段話可以得出，我的需求是第一種~也就是只需要在線程內添加一個Cookie Manager配置元件即可。
1、添加HTTP Cookie 管理器
2、執行測試
bingo~~~~~~~
access_token所在的URI正確獲取到，POST請求中也傳入了cookie.
參考資料：
OAuth2.0
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
Jmeter
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cookie_Manager
接口測試工具-Jmeter使用筆記（八：模擬OAuth2.0協議簡化模式的請求）