感覺自己最近銷聲匿跡快一個月了，應該總結下自己這個月學習的東西了~~~折騰完公司私有協議的接口測試（c++接口），開始折騰公司的http/https接口和webservice接口的測試，想着把所有的這些接口盡量的都放在RobotFrameWork內進行測試，其實這些接口，http/https接口和webservice接口之前已經能用SoapUI或者LoadRunner實現了測試，而且webservice接口我有專門用myeclipse結合TestNG框架和XFIRE框架搭建了數據驅動的自動化測試工具，但是前者沒有實現自動化，參數寫死在腳本內，后者技術性太強，一般測試不會用。而且測試里也沒有詳細的測試報告，於是我就想着全部移植到RF內。
基於https協議的接口，是因為公司有部分業務采用了Oauth2.0協議來開發的，自己做的認證服務器，也做了資源服務器，主要是采用spring mvc、openjpa框架來實現的，底層的數據傳輸采用HTTPS協議，返回值數據格式采用的是標准JSON格式。
首先：應該了解Oauth2.0協議的基本概念，基本應用場景
OAUTH協議為用戶資源的授權提供了一個安全的、開放而又簡易的標准。與以往的授權方式不同之處是OAUTH的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAUTH是安全的。oAuth是Open Authorization的簡寫。官方網址：http://oauth.net。
常見應用場景：在京東上可以不注冊用戶，用戶可以直接用qq號登陸即可。
在Oauth當中有四個角色：
A：Resource Owner(RO):資源所有者，資源可以類似於照片，文檔，會員信息等等。對應於上面應用場景中的用戶，用戶擁有的資源都是被保護的資源。
B: resource server資源服務器：保存資源的服務器.訪問資源服務器就要出示 Access Token。對應上面場景中的京東，qq用戶需要攜帶Access Token才能正常訪問京東服務器（不然用其他APP的賬號咋就不能登呢，嘿嘿）。
C：client客戶端：拿到Token授權后，可以代表資源所有者訪問資源服務器。對應上面場景中的京東。
D: authorization server授權服務器：對資源所有者進行認證，認證通過后，向 客戶端發放 Access Token,對應上面場景中的qq服務器。
然后：了解下oauth協議的總體處理流程。
不同的公司，不同的授權模式，處理流程應該是不一樣的，這里就以上面的應用場景為例，說明下大致的業務流程：
Step1：申請接入，從騰訊獲取appid和apikey；
Step2：開發應用，並設置協作者帳號進行測試聯調；
Step3：放置QQ登錄按鈕；
Step4：通過用戶登錄驗證和授權，獲取Access Token；
Step5：通過Access Token獲取用戶的OpenID；
Step6：調用OpenAPI，來請求訪問或修改用戶授權的資源。
上面的業務流程主要還是來自http://wiki.connect.qq.com，騰訊官網提供給第三方應用使用的，從這里可以加深對oauth協議的了解，下面是官網里面的流程圖
簡單點的可以看下面的圖：
最后：OAuth定義的4種授權類型
第一種：Authorization Code授權碼方式（最安全）：
qq就是采用這種方式進行授權的，大致流程如下：
（A）用戶訪問客戶端，后者將前者導向認證服務器。
（B）用戶選擇是否給予客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個授權碼。
（D）客戶端收到授權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的后台的服務器上完成的，對用戶不可見。
（E）認證服務器核對了授權碼和重定向URI，確認無誤后，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。
第二種：Implicit Grant隱式授權：相比授權碼授權，隱式授權少了第一步的取Authorization Code的過程，而且不會返回 refresh_token。大致流程如下：
（A）客戶端將用戶導向認證服務器。
（B）用戶決定是否給於客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。
（E）資源服務器返回一個網頁，其中包含的代碼可以獲取Hash值中的令牌。
（F）瀏覽器執行上一步獲得的腳本，提取出令牌。
（G）瀏覽器將令牌發給客戶端。
第三種：Resource Owner Password Credentials資源所有者密碼證書授權：這種驗證主要用於資源所有者對Client有極高的信任度的情況，比如操作系統或高權限程序。只有在不能使用其它授權方式的情況下才使用這種方式。我做的這個項目就是采用的這種授權類型，主要流程如下：
（A）用戶向客戶端提供用戶名和密碼。
（B）客戶端將用戶名和密碼發給認證服務器，向后者請求令牌。
（C）認證服務器確認無誤后，向客戶端提供訪問令牌。
第四種：Client Credentials客戶端證書授權：這種情況下 Client使用自己的 client證書（如 client_id及client_secret組成的 http basic驗證碼）來獲取 access token，只能用於信任的client。
（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。
（B）認證服務器確認無誤后，向客戶端提供訪問令牌。
對這個講解很深入的可以參考http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html