摘要：作為目前最主流的微服務(wù)框架，發(fā)展速度很快，成為了最全面的微服務(wù)解決方案。通過認(rèn)證后，轉(zhuǎn)發(fā)給內(nèi)部相應(yīng)的服務(wù)器。所有遠(yuǎn)程訪問資源服務(wù)器相關(guān)的必須提供。

作者 freewolf

微服務(wù)、Spring Cloud、OAuth 2.0、JWT、Spring Security、SSO、UAA

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

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

老話題！“如何才能在微服務(wù)體系中保證安全？”，為了達(dá)成目標(biāo)，這里采用一個簡單而可行方式來保護(hù)Spring Cloud中服務(wù)的安全，也就是建立統(tǒng)一的用戶授權(quán)中心。

這里補(bǔ)充說一下什么是Authentication（認(rèn)證）和Authorization（鑒權(quán)），其實(shí)很簡單，認(rèn)證關(guān)心你是誰，鑒權(quán)關(guān)心你能干什么。舉個大家一致都再說的例子，如果你去機(jī)場乘機(jī)，你持有的護(hù)照代表你的身份，這是認(rèn)證，你的機(jī)票就是你的權(quán)限，你能干什么。

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

為了高效的實(shí)現(xiàn)這個目標(biāo)，這里采用OAuth 2和JWT(JSON Web Tokens)技術(shù)作為解決方案，

盡管微服務(wù)在現(xiàn)代軟件開發(fā)中還算一個新鮮事物，但是OAuth 2已經(jīng)是一個廣泛使用的授權(quán)技術(shù)，它讓W(xué)eb開發(fā)者在自己提供服務(wù)中，用一種安全的方式直訪問Google/Facebook/GitHub平臺用戶信息。但在我開始闡述細(xì)節(jié)之前，我將揭開聚焦到本文真正的主題：云安全

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

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

其他方式:我們?yōu)樗蟹?wù)建立統(tǒng)一的權(quán)限數(shù)據(jù)庫，并在每次請求前對用戶進(jìn)行鑒權(quán)，聽起來某些方面的確有點(diǎn)愚蠢，但實(shí)際上這確實(shí)是一個可行的安全方案。

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

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

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

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

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

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

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

授權(quán)服務(wù)器(Authorization Server) - 這里當(dāng)然還是Facebook，因?yàn)镕acebook有相關(guān)數(shù)據(jù)

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

當(dāng)Tom試圖登錄Facebook，某App將他重定向到Facebook的授權(quán)服務(wù)器，當(dāng)Tom登錄成功，并且許可自己的Email和個人信息被某App獲取。這兩個資源被定義成一個Scope（權(quán)限范圍），一旦準(zhǔn)許，某App的開發(fā)者就可以申請?jiān)L問權(quán)限范圍中定義的這兩個資源。

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

到目前為止，我們?nèi)绾沃苯訉⒁陨蟽?nèi)容用于實(shí)際的例子中？OAuth 2十分友好，并容易部署，所有交互都是關(guān)于客戶端和權(quán)限范圍的。

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

我需要將授權(quán)映射到權(quán)限范圍中或?qū)⒂脩粲成涞娇蛻舳酥校?/p>

為什么我需要客戶端？

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

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

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

在一個在線商店中，前端可以看做一個客戶端，可以訪問商品、訂單和客戶信息，但后端可以關(guān)于物流和合同等，另一方面，用戶可以訪問一個服務(wù)但并不是全部的數(shù)據(jù)，這可以是因?yàn)橛脩粽谑褂肳eb應(yīng)用，當(dāng)他不能的時候，其他用戶卻可以。服務(wù)之間的訪問時我們要討論的另一個維度。如果你熟悉數(shù)學(xué)，我可以說在OAuth 2中，客戶端-權(quán)限范圍關(guān)系是線性獨(dú)立于用戶-權(quán)限關(guān)系。

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

當(dāng)我們談及微服務(wù)時，我們需要找一個Token存儲的方式，來保證授權(quán)服務(wù)器可以被水平擴(kuò)展，盡管這是一個很復(fù)雜的任務(wù)。所有訪問微服務(wù)資源的請求都在Http Header中攜帶Token，被訪問的服務(wù)接下來再去請求授權(quán)服務(wù)器驗(yàn)證Token的有效性，目前這種方式，我們需要兩次或者更多次的請求，但這是為了安全性也沒什么其他辦法。但擴(kuò)展Token存儲會很大影響我們系統(tǒng)的可擴(kuò)展性，這是我們引入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     |             |
+-----------+                                     +-------------+

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

驗(yàn)證服務(wù)器返回的信息可以是以下內(nèi)容：

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

refresh_token - 當(dāng)訪問令牌失效，使用這個令牌重新獲取訪問令牌

token_type - 令牌類型，這里是Bearer也就是基本HTTP認(rèn)證

expire_in - 過期時間

jti - JWT ID

由于Access Token是Base64編碼，反編碼后就是下面的格式，標(biāo)準(zhǔn)的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字符串中包含用戶信息和權(quán)限范圍，我們所需的全部信息都有了，所以不需要維護(hù)Token存儲，資源服務(wù)器也不必要求Token檢查。

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

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

如果您感興趣，后面還會有實(shí)現(xiàn)部分，敬請期待~

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