摘要：作為目前最主流的微服務框架，發展速度很快，成為了最全面的微服務解決方案。通過認證后，轉發給內部相應的服務器。所有遠程訪問資源服務器相關的必須提供。

作者 freewolf

微服務、Spring Cloud、OAuth 2.0、JWT、Spring Security、SSO、UAA

作為從業了十多年的IT行業和程序的老司機，今天如果你說你不懂微服務，都不好意思說自己的做軟件的。SOA喊了多年，無人不知，但又有多少系統開發真正的SOA了呢？但是好像一夜之間所有人都投入了微服務的懷抱。

作為目前最主流的“微服務框架”，Spring Cloud發展速度很快，成為了最全面的微服務解決方案。不管什么軟件體系，什么框架，安全永遠是不可能繞開的話題，我也把它作為我最近一段時間研究微服務的開篇。

老話題！“如何才能在微服務體系中保證安全？”，為了達成目標，這里采用一個簡單而可行方式來保護Spring Cloud中服務的安全，也就是建立統一的用戶授權中心。

這里補充說一下什么是Authentication（認證）和Authorization（鑒權），其實很簡單，認證關心你是誰，鑒權關心你能干什么。舉個大家一致都再說的例子，如果你去機場乘機，你持有的護照代表你的身份，這是認證，你的機票就是你的權限，你能干什么。

學習微服務并不是一個簡單的探索過程，這不得學習很多新的知識，其實不管是按照DDD（Domain Driven Design）領域驅動設計中領域模型的方式，還是將微服務拆分成更小的粒度。都會遇到很多新的問題和以前一直都沒解決很好的問題。隨著不斷的思考，隨著熟悉Facebook/GitHub/AWS這些機構是如何保護內部資源，答案也逐漸浮出水面。

為了高效的實現這個目標，這里采用OAuth 2和JWT(JSON Web Tokens)技術作為解決方案，

盡管微服務在現代軟件開發中還算一個新鮮事物，但是OAuth 2已經是一個廣泛使用的授權技術，它讓Web開發者在自己提供服務中，用一種安全的方式直訪問Google/Facebook/GitHub平臺用戶信息。但在我開始闡述細節之前，我將揭開聚焦到本文真正的主題：云安全

那么在云服務中對用戶訪問資源的控制，我們一般都怎么做呢？然我舉一些大家似乎都用過的但又不是很完美的例子。

我們可以設置邊界服務器或者帶認證功能的反向代理服務器，假設所有訪問請求都發給它。通過認證后，轉發給內部相應的服務器。一般在Spring MVC Security開發中幾乎都會這樣做的。但這并不安全，最重要的是，一旦是有人從內部攻擊，你的數據毫無安全性。

其他方式:我們為所有服務建立統一的權限數據庫，并在每次請求前對用戶進行鑒權，聽起來某些方面的確有點愚蠢，但實際上這確實是一個可行的安全方案。

更好的方式: 用戶通過授權服務來實現鑒權，把用戶訪問Session映射成一個Token。所有遠程訪問資源服務器相關的API必須提供Token。然后資源服務器訪問授權服務來識別Token，得知Token屬于哪個用戶，并了解通過這個Token可以訪問什么資源。

這聽起來是個不錯的方案，對不？但是如何保證Token的安全傳輸？如何區分是用戶訪問還是其他服務訪問？這肯定是我們關心的問題。

所以上述種種問題讓我們選擇使用OAuth 2，其實訪問Facebook/Google的敏感數據和訪問我們自己后端受保護數據沒什么區別，并且他們已經使用這樣的解決方案很多年，我們只要遵循這些方法就好了。

如果你了解OAuth 2相關的原理，那么在部署OAuth 2是非常容易的。
讓我們描述下這樣一個場景，“某App希望獲得Tom在Facebook上相關的數據”

OAuth 2 在整個流程中有四種角色:

資源擁有者(Resource Owner) - 這里是Tom

資源服務器(Resource Server) - 這里是Facebook

授權服務器(Authorization Server) - 這里當然還是Facebook，因為Facebook有相關數據

客戶端(Client) - 這里是某App

當Tom試圖登錄Facebook，某App將他重定向到Facebook的授權服務器，當Tom登錄成功，并且許可自己的Email和個人信息被某App獲取。這兩個資源被定義成一個Scope（權限范圍），一旦準許，某App的開發者就可以申請訪問權限范圍中定義的這兩個資源。

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Tom允許了權限請求，再次通過重定向返回某App，重定向返回時攜帶了一個Access Token（訪問令牌），接下來某App就可以通過這個Access Token從Facebook直接獲取相關的授權資源（也就是Email和個人信息），而無需重新做Tom相關的鑒權。而且每當Tom登錄了某App，都可以通過之前獲得的Access Token，直接獲取相關授權資源。

到目前為止，我們如何直接將以上內容用于實際的例子中？OAuth 2十分友好，并容易部署，所有交互都是關于客戶端和權限范圍的。

OAuth 2中的客戶端和權限范圍和我們平時的用戶和權限是否相同？

我需要將授權映射到權限范圍中或將用戶映射到客戶端中？

為什么我需要客戶端？

你也許在之前在類似的企業級開發案例中嘗試映射過相關的角色。這會很棘手！

任何類型的應用都提供用戶登錄，登錄結果是一個Access Token，所有的之后的API調用都將這個Access Token加入HTTP請求頭中，被調用服務去授權服務器驗證Access Token并獲取該Token可訪問的權限信息。這樣一來，所有服務的訪問都會請求另外的服務來完成鑒權。

在OAuth 2中，你可以定義哪個應用（網站、移動客戶端、桌面應用、其他）可以訪問那些資源。這里只有一個尺寸，來自哪里的哪個用戶可以訪問那些數據，當然也是哪個應用或者服務可以訪問那些資源。換一種說法，權限范圍就是控制那些端點對客戶端可見，或者用戶根據他的權限來獲取相關的數據。

在一個在線商店中，前端可以看做一個客戶端，可以訪問商品、訂單和客戶信息，但后端可以關于物流和合同等，另一方面，用戶可以訪問一個服務但并不是全部的數據，這可以是因為用戶正在使用Web應用，當他不能的時候，其他用戶卻可以。服務之間的訪問時我們要討論的另一個維度。如果你熟悉數學，我可以說在OAuth 2中，客戶端-權限范圍關系是線性獨立于用戶-權限關系。

OAuth 2并不關心去哪找Access Token和把它存在什么地方的，生成隨機字符串并保存Token相關的數據到這些字符串中保存好。通過一個令牌端點，其他服務可能會關心這個Token是否有效，它可以通過哪些權限。這就是用戶信息URL方法，授權服務器為了獲取用戶信息轉換為資源服務器。

當我們談及微服務時，我們需要找一個Token存儲的方式，來保證授權服務器可以被水平擴展，盡管這是一個很復雜的任務。所有訪問微服務資源的請求都在Http Header中攜帶Token，被訪問的服務接下來再去請求授權服務器驗證Token的有效性，目前這種方式，我們需要兩次或者更多次的請求，但這是為了安全性也沒什么其他辦法。但擴展Token存儲會很大影響我們系統的可擴展性，這是我們引入JWT（讀jot）的原因。

+-----------+                                     +-------------+
|           |       1-Request Authorization       |             |
|           |------------------------------------>|             |
|           |     grant_type&username&password    |             |--+
|           |                                     |Authorization|  | 2-Gen
|  Client   |                                     |Service      |  |   JWT
|           |       3-Response Authorization      |             |<-+
|           |<------------------------------------| Private Key |
|           |    access_token / refresh_token     |             |
|           |    token_type / expire_in / jti     |             |
+-----------+                                     +-------------+

簡短來說，響應一個用戶請求時，將用戶信息和授權范圍序列化后放入一個JSON字符串，然后使用Base64進行編碼，最終在授權服務器用私鑰對這個字符串進行簽名，得到一個JSON Web Token，我們可以像使用Access Token一樣的直接使用它，假設其他所有的資源服務器都將持有一個RSA公鑰。當資源服務器接收到這個在Http Header中存有Token的請求，資源服務器就可以拿到這個Token，并驗證它是否使用正確的私鑰簽名（是否經過授權服務器簽名，也就是驗簽）。驗簽通過，反序列化后就拿到OAuth 2的驗證信息。

驗證服務器返回的信息可以是以下內容：

access_token - 訪問令牌，用于資源訪問

refresh_token - 當訪問令牌失效，使用這個令牌重新獲取訪問令牌

token_type - 令牌類型，這里是Bearer也就是基本HTTP認證

expire_in - 過期時間

jti - JWT ID

由于Access Token是Base64編碼，反編碼后就是下面的格式，標準的JWT格式。也就是Header、 Payload、Signature三部分。

{ 
  "alg":"RS256",
  "typ":"JWT"
}
{
  "exp": 1492873315,
  "user_name": "reader",
  "authorities": [
    "AURH_READ"
  ],
  "jti": "8f2d40eb-0d75-44df-a8cc-8c37320e3548",
  "client_id": "web_app",
  "scope": [
    "FOO"
  ]
}
&:l?s)?-[+
F"2"K?8??:u9??? 9Q32Z??$ec{3mxJh?0DF庖[!?N)?knVV?V|夻?E?}?f9>"<蕱?B?е?ov虀D?8C4K}Em??    YVcaqIW&*u?u?b!?*??-{?X?WTq

使用JWT可以簡單的傳輸Token，用RSA簽名保證Token很難被偽造。Access Token字符串中包含用戶信息和權限范圍，我們所需的全部信息都有了，所以不需要維護Token存儲，資源服務器也不必要求Token檢查。

+-----------+                                    +-----------+
|           |       1-Request Resource           |           |
|           |----------------------------------->|           |
|           | Authorization: bearer Access Token |           |--+
|           |                                    | Resource  |  | 2-Verify
|  Client   |                                    | Service   |  |  Token
|           |       3-Response Resource          |           |<-+
|           |<-----------------------------------| Public Key|
|           |                                    |           |
+-----------+                                    +-----------+

所以，在微服務中使用OAuth 2，不會影響到整體架構的可擴展性。淡然這里還有一些問題沒有涉及，例如Access Token過期后，使用Refresh Token到認證服務器重新獲取Access Token等，后面會有具體的例子來展開討論這些問題。

如果您感興趣，后面還會有實現部分，敬請期待~

由于 http://asciiflow.com/ 流程圖使用中文就無法對齊了，本文中流程圖都是英文了~