Spring Cloud Security 之 OAuth2.0

 

參考文章：http://www.cnblogs.com/Irving/p/9343377.html

 

1、 OAuth2.0 基礎

　　概念：OAuth2.0 一個受權框架，它容許用戶讓第三方應用訪問該用戶在某服務的特定私有資源，可是不提供帳號密碼消息給第三方應用

　　角色： 

• • resource owner（資源全部者）
  • resource server（資源服務器）
  • client（客戶端）：表明資源全部者而且通過全部者受權去訪問受保護的資源的應用程序
  • authorization server（受權服務器）：在成功驗證資源全部者並得到受權後向客戶端發出訪問令牌

　　受權模式：

　　Authorization code（受權碼模式）

　　標準的 Server 受權模式，很是適合 Server 端的 Web 應用。一旦資源的擁有者受權訪問他們的數據以後，他們將會被重定向到 Web 應用並在 URL 的查詢參數中附帶一個受權碼（code）。在客戶端裏，該 code 用於請求訪問令牌（access_token）。而且該令牌交換的過程是兩個服務端以前完成的，防止其餘人甚至是資源擁有者本人獲得該令牌。另外，在該受權模式下能夠經過 refresh_token 來刷新令牌以延長訪問受權時間，也是最爲複雜的一種方式。

　　Implicit Grant（隱式模式）

　　該模式是全部受權模式中最簡單的一種，併爲運行於瀏覽器中的腳本應用作了優化。當用戶訪問該應用時，服務端會當即生成一個新的訪問令牌（access_token）並經過URL的#hash段傳回客戶端。這時，客戶端就能夠利用JavaScript等將其取出而後請求API接口。該模式不須要受權碼（code），固然也不會提供refresh token以得到長期訪問的入口。

　　Resource Owner Password Credentials（密碼模式）

　　本身有一套用戶體系，這種模式要求用戶提供用戶名和密碼來交換訪問令牌（access_token）。該模式僅用於很是值得信任的用戶，例如API提供者本人所寫的移動應用。雖然用戶也要求提供密碼，但並不須要存儲在設備上。由於初始驗證以後，只需將 OAuth 的令牌記錄下來便可。若是用戶但願取消受權，由於其真實密碼並無被記錄，所以無需修改密碼就能夠當即取消受權。token自己也只是獲得有限的受權，所以相比最傳統的 username/password 受權，該模式依然更爲安全。

　　Client Credentials（客戶端模式）

　　沒有用戶的概念，一種基於 APP 的密鑰直接進行受權，所以 APP 的權限很是大。它適合像數據庫或存儲服務器這種對 API 的訪問需求。

 

2、OAuth2.0受權流程

　　

1. (A)  客戶端向資源全部者請求其受權
2. (B)  客戶端收到資源全部者的受權許可，這個受權許但是一個表明資源全部者受權的憑據
3. (C)  客戶端向受權服務器請求訪問令牌，並出示受權許可
4. (D)  受權服務器對客戶端身份進行認證，並校驗受權許可，若是都是有效的，則發放訪問令牌
5. (E)  客戶端向資源服務器請求受保護的資源，並出示訪問令牌
6. (F)  資源服務器校驗訪問令牌，若是令牌有效，則提供服務

3、Refresh Token流程

　　

　　刷新的流程如圖所示：

1. (A)  客戶端請求獲取訪問令牌，並向受權服務器提供受權許可
2. (B)  受權服務器對客戶端身份進行認證，並校驗受權許可，若是校驗經過，則發放訪問令牌和刷新令牌
3. (C)  客戶端訪問受保護的資源，並向資源服務器提供訪問令牌
4. (D)  資源服務器校驗訪問令牌，若是校驗經過，則提供服務
5. (E)  重複(C)和(D)直到訪問令牌過時。若是客戶端直到訪問令牌已通過期，則跳至(G)，不然不能繼續訪問受保護的資源
6. (F)  自從訪問令牌失效之後，資源服務器返回一個無效的令牌錯誤
7. (G)  客戶端請求獲取一個新的訪問令牌，並提供刷新令牌
8. (H)  受權服務器對客戶端進行身份認證並校驗刷新令牌，若是校驗經過，則發放新的訪問令牌（而且，可選的發放新的刷新令牌）