微服務架構之「 訪問安全 」

應用程序的訪問安全又是咱們每個研發團隊都必須關注的重點問題。尤爲是在咱們採用了微服務架構以後，項目的複雜度提高了N個級別，相應的，微服務的安全工做也就更難更復雜了。而且咱們以往擅長的單體應用的安全方案對於微服務來講已經再也不適用了。咱們必須有一套新的方案來保障微服務架構的安全。

在探索微服務訪問安全以前，咱們仍是先來回顧一下單體應用的安全是如何實現的。

1、傳統單體應用如何實現「訪問安全」？

下圖就是一個傳統單體應用的訪問示意圖：

（圖片來自WillTran在slideshare分享）

在應用服務器裏面，咱們有一個auth模塊（通常採用過濾來實現），當有客戶端請求進來時，全部的請求都必須首先通過這個auth來作身份驗證，驗證經過後，纔將請求發到後面的業務邏輯。

一般客戶端在第一次請求的時候會帶上身份校驗信息（用戶名和密碼），auth模塊在驗證信息無誤後，就會返回Cookie存到客戶端，以後每次客戶端只須要在請求中攜帶Cookie來訪問，而auth模塊也只須要校驗Cookie的合法性後決定是否放行。

可見，在傳統單體應用中的安全架構仍是蠻簡單的，對外也只有一個入口，經過auth校驗後，內部的用戶信息都是內存/線程傳遞，邏輯並非複雜，因此風險也在可控範圍內。

那麼，當咱們的項目改成微服務以後，「訪問安全」又該怎麼作呢。

2、微服務如何實現「訪問安全」？

在微服務架構下，有如下三種方案能夠選擇，固然，用的最多的確定仍是OAuth模式。

• 網關鑑權模式（API Gateway）

• 服務自主鑑權模式

• API Token模式（OAuth2.0）

下面分別來說一下這三種模式：

1. 網關鑑權模式（API Gateway）

   （圖片來自WillTran在slideshare分享）

   經過上圖可見，由於在微服務的最前端通常會有一個API網關模塊（API Gateway），全部的外部請求訪問微服務集羣時，都會首先經過這個API Gateway，因此咱們能夠在這個模塊裏部署auth邏輯，實現統一集中鑑權，鑑權經過後，再把請求轉發給後端各個服務。

   這種模式的優勢就是，由API Gateway集中處理了鑑權的邏輯，使得後端各微服務節點自身邏輯就簡單了，只須要關注業務邏輯，無需關注安全性事宜。

   這個模式的問題就是，API Gateway適用於身份驗證和簡單的路徑受權（基於URL的），對於複雜數據/角色的受權訪問權限，經過API Gateway很難去靈活的控制，畢竟這些邏輯都是存在後端服務上的，並不是存儲在API Gateway裏。

2. 服務自主鑑權模式

   （圖片來自WillTran在slideshare分享）

   服務自主鑑權就是指不經過前端的API Gateway來控制，而是由後端的每個微服務節點本身去鑑權。

   它的優勢就是能夠由更爲靈活的訪問受權策略，而且至關於微服務節點徹底無狀態化了。同時還能夠避免API Gateway 中 auth 模塊的性能瓶頸。

   缺點就是因爲每個微服務都自主鑑權，當一個請求要通過多個微服務節點時，會進行重複鑑權，增長了不少額外的性能開銷。

3. API Token模式（OAuth2.0）

   （圖片來自網絡）

   如圖，這是一種採用基於令牌Token的受權方式。在這個模式下，是由受權服務器（圖中Authorization Server）、API網關（圖中API Gateway）、內部的微服務節點幾個模塊組成。

   流程以下：

   第一步：客戶端應用首先使用帳號密碼或者其它身份信息去訪問受權服務器（Authorization Server）獲取 訪問令牌（Access Token）。

   第二步：拿到訪問令牌（Access Token）後帶着它再去訪問API網關（圖中API Gateway），API Gateway本身是沒法判斷這個Access Token是否合法的，因此走第三步。

   第三步：API Gateway去調用Authorization Server校驗一下Access Token的合法性。

   第四步：若是驗證完Access Token是合法的，那API Gateway就將Access Token換成JWT令牌返回。

   （注意：此處也能夠不換成JWT而是直接返回原Access Token。可是換成JWT更好，由於Access Token是一串不可讀無心義的字符串，每次驗證Access Token是否合法都須要去訪問Authorization Server才知道。可是JWT令牌是一個包含JOSN對象，有用戶信息和其它數據的一個字符串，後面微服務節點拿到JWT以後，本身就能夠作校驗，減小了交互次數）。

   第五步：API Gateway有了JWT以後，就將請求向後端微服務節點進行轉發，同時會帶上這個JWT。

   第六步：微服務節點收到請求後，讀取裏面的JWT，而後經過加密算法驗證這個JWT，驗證經過後，就處理請求邏輯。

   這裏面就使用到了OAuth2.0的原理，不過這只是OAuth2.0各種模式中的一種。

因爲OAuth2.0目前最爲經常使用，因此接下來我再來詳細講解一下OAuth2.0的原理和各種用法。

3、詳解 OAuth2.0 的「 訪問安全 」？

OAuth2.0是一種訪問受權協議框架。它是基於Token令牌的受權方式，在不暴露用戶密碼的狀況下，使 應用方 可以獲取到用戶數據的訪問權限。

例如：你開發了一個視頻網站，能夠採用第三方微信登錄，那麼只要用戶在微信上對這個網站受權了，那這個網站就能夠在無需用戶密碼的狀況下獲取用戶在微信上的頭像。

OAuth2.0 的流程以下圖：

OAuth2.0 裏的主要名詞有：

• 資源服務器：用戶數據/資源存放的地方，在微服務架構中，服務就是資源服務器。在上面的例子中，微信頭像存放的服務就是資源服務器。

• 資源擁有者：是指用戶，資源的擁有人。在上面的例子中某個微信頭像的用戶就是資源擁有者。

• 受權服務器：是一個用來驗證用戶身份並頒發令牌的服務器。

• 客戶端應用：想要訪問用戶受保護資源的客戶端/Web應用。在上面的例子中的視頻網站就是客戶端應用。

• 訪問令牌：Access Token，授予對資源服務器的訪問權限額度令牌。

• 刷新令牌：客戶端應用用於獲取新的 Access Token 的一種令牌。

• 客戶憑證：用戶的帳號密碼，用於在 受權服務器 進行驗證用戶身份的憑證。

OAuth2.0有四種受權模式，也就是四種獲取令牌的方式：受權碼、簡化式、用戶名密碼、客戶端憑證。

下面來分別講解一下：

1. 受權碼（Authorization Code）

   受權碼模式是指：客戶端應用先去申請一個受權碼，而後再拿着這個受權碼去獲取令牌的模式。這也是目前最爲經常使用的一種模式，安全性比較高，適用於咱們經常使用的先後端分離項目。經過前端跳轉的方式去訪問 受權服務器 獲取受權碼，而後後端再用這個受權碼訪問 受權服務器 以獲取 訪問令牌。

   流程如上圖。

   第一步，客戶端的前端頁面(圖中UserAgent)將用戶跳轉到 受權服務器(Authorization Server)裏進行受權，受權完成後，返回 受權碼(Authorization Code)

   第二步，客戶端的後端服務(圖中Client)攜帶受權碼(Authorization Code)去訪問 受權服務器，而後得到正式的 訪問令牌(Access Token)

   頁面的前端和後端分別作不一樣的邏輯，前端接觸不到Access Token，保證了Access Token的安全性。

2. 簡化式（Implicit）

   簡化模式是在項目是一個純前端應用，在沒有後端的狀況下，採用的一種模式。

   由於這種方式令牌是直接存在前端的，因此很是不安全，所以令牌的有限期設置就不能太長。

   其流程就是：

   第一步：應用（純前端的應用）將用戶跳轉到 受權服務器(Authorization Server)裏進行受權，受權完成後，受權服務器 直接將 Access Token 返回給 前端應用，令牌存儲在前端頁面。

   第二步：應用（純前端的應用）攜帶 訪問令牌(Access Token) 去訪問資源，獲取資源。

   在整個過程當中，雖然令牌是在前端URL中直接傳遞，但注意，令牌在HTTP協議中不是放在URL參數字段中的，而是放在URL錨點裏。由於錨點數據不會被瀏覽器發到服務器，所以有必定的安全保障。

3. 用戶名密碼（Resource Owner Credentials）

   這種方式最容易理解了，直接使用用戶的用戶名/密碼做爲受權方式去訪問 受權服務器，從而獲取Access Token，這個方式由於須要用戶給出本身的密碼，因此很是的不安全性。通常僅在客戶端應用與受權服務器、資源服務器是歸屬統一公司/團隊，互相很是信任的狀況下采用。

4. 客戶端憑證（Client Credentials）

   這是適用於服務器間通訊的場景。客戶端應用拿一個用戶憑證去找受權服務器獲取Access Token。

以上，就是對微服務架構中「訪問安全」的一些思考。

在微服務架構的系列文章中，前面已經經過文章介紹過了「服務註冊 」、「服務網關 」、「配置中心 」、「 監控系統 」、「調用鏈監控」、「容錯隔離」，你們能夠翻閱歷史文章查看。

碼字不易啊，喜歡的話不妨轉發朋友，或點擊文章右下角的「在看」吧。😊

本文原創發佈於微信公衆號「 不止思考 」，歡迎關注。涉及 思惟認知、我的成長、架構、大數據、Web技術 等。