微服務架構之「 訪問安全 」
應用程式的訪問安全又是我們每一個研發團隊都必須關注的重點問題。尤其是在我們採用了微服務架構之後，專案的複雜度提升了N個級別，相應的，微服務的安全工作也就更難更復雜了。並且我們以往擅長的單體應用的安全方案對於微服務來說已經不再適用了。我們必須有一套新的方案來保障微服務架構的安全。
在探索微服務訪問安全之前，我們還是先來回顧一下單體應用的安全是如何實現的。
一、傳統單體應用如何實現「訪問安全」？
下圖就是一個傳統單體應用的訪問示意圖：
（圖片來自WillTran在slideshare分享）
在應用伺服器裡面，我們有一個auth模組（一般採用過濾來實現），當有客戶端請求進來時，所有的請求都必須首先經過這個auth來做身份驗證，驗證通過後，才將請求發到後面的業務邏輯。
通常客戶端在第一次請求的時候會帶上身份校驗資訊（使用者名稱和密碼），auth模組在驗證資訊無誤後，就會返回Cookie存到客戶端，之後每次客戶端只需要在請求中攜帶Cookie來訪問，而auth模組也只需要校驗Cookie的合法性後決定是否放行。
可見，在傳統單體應用中的安全架構還是蠻簡單的，對外也只有一個入口，通過auth校驗後，內部的使用者資訊都是記憶體/執行緒傳遞，邏輯並不是複雜，所以風險也在可控範圍內。
那麼，當我們的專案改為微服務之後，「訪問安全」又該怎麼做呢。
二、微服務如何實現「訪問安全」？
在微服務架構下，有以下三種方案可以選擇，當然，用的最多的肯定還是OAuth模式。
-
閘道器鑑權模式（API Gateway）
-
服務自主鑑權模式
-
API Token模式（OAuth2.0）
下面分別來講一下這三種模式：
-
閘道器鑑權模式（API Gateway）
（圖片來自WillTran在slideshare分享）通過上圖可見，因為在微服務的最前端一般會有一個API閘道器模組（API Gateway），所有的外部請求訪問微服務叢集時，都會首先通過這個API Gateway，所以我們可以在這個模組裡部署auth邏輯，實現統一集中鑑權，鑑權通過後，再把請求轉發給後端各個服務。
這種模式的優點就是，由API Gateway集中處理了鑑權的邏輯，使得後端各微服務節點自身邏輯就簡單了，只需要關注業務邏輯，無需關注安全性事宜。
這個模式的問題就是，API Gateway適用於身份驗證和簡單的路徑授權（基於URL的），對於複雜資料/角色的授權訪問許可權，通過API Gateway很難去靈活的控制，畢竟這些邏輯都是存在後端服務上的，並非儲存在API Gateway裡。
-
服務自主鑑權模式
（圖片來自WillTran在slideshare分享）
服務自主鑑權就是指不通過前端的API Gateway來控制，而是由後端的每一個微服務節點自己去鑑權。
它的優點就是可以由更為靈活的訪問授權策略，並且相當於微服務節點完全無狀態化了。同時還可以避免API Gateway 中 auth 模組的效能瓶頸。
缺點就是由於每一個微服務都自主鑑權，當一個請求要經過多個微服務節點時，會進行重複鑑權，增加了很多額外的效能開銷。
-
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的原理和各類用法。
三、詳解 OAuth2.0 的「 訪問安全 」？
OAuth2.0是一種訪問授權協議框架。它是基於Token令牌的授權方式，在不暴露使用者密碼的情況下，使 應用方 能夠獲取到使用者資料的訪問許可權。
例如：你開發了一個視訊網站，可以採用第三方微信登陸，那麼只要使用者在微信上對這個網站授權了，那這個網站就可以在無需使用者密碼的情況下獲取使用者在微信上的頭像。
OAuth2.0 的流程如下圖：
OAuth2.0 裡的主要名詞有：
-
資源伺服器：使用者資料/資源存放的地方，在微服務架構中，服務就是資源伺服器。在上面的例子中，微信頭像存放的服務就是資源伺服器。
-
資源擁有者：是指使用者，資源的擁有人。在上面的例子中某個微信頭像的使用者就是資源擁有者。
-
授權伺服器：是一個用來驗證使用者身份並頒發令牌的伺服器。
-
客戶端應用：想要訪問使用者受保護資源的客戶端/Web應用。在上面的例子中的視訊網站就是客戶端應用。
-
訪問令牌：Access Token，授予對資源伺服器的訪問許可權額度令牌。
-
重新整理令牌：客戶端應用用於獲取新的 Access Token 的一種令牌。
-
客戶憑證：使用者的賬號密碼，用於在 授權伺服器 進行驗證使用者身份的憑證。
OAuth2.0有四種授權模式，也就是四種獲取令牌的方式：授權碼、簡化式、使用者名稱密碼、客戶端憑證。
下面來分別講解一下：
-
授權碼（Authorization Code）
授權碼模式是指：客戶端應用先去申請一個授權碼，然後再拿著這個授權碼去獲取令牌的模式。這也是目前最為常用的一種模式，安全性比較高，適用於我們常用的前後端分離專案。通過前端跳轉的方式去訪問 授權伺服器 獲取授權碼，然後後端再用這個授權碼訪問 授權伺服器 以獲取 訪問令牌。
流程如上圖。第一步，客戶端的前端頁面(圖中UserAgent)將使用者跳轉到 授權伺服器(Authorization Server)裡進行授權，授權完成後，返回 授權碼(Authorization Code)
第二步，客戶端的後端服務(圖中Client)攜帶授權碼(Authorization Code)去訪問 授權伺服器，然後獲得正式的 訪問令牌(Access Token)
頁面的前端和後端分別做不同的邏輯，前端接觸不到Access Token，保證了Access Token的安全性。
-
簡化式（Implicit）
簡化模式是在專案是一個純前端應用，在沒有後端的情況下，採用的一種模式。
因為這種方式令牌是直接存在前端的，所以非常不安全，因此令牌的有限期設定就不能太長。
其流程就是：第一步：應用（純前端的應用）將使用者跳轉到 授權伺服器(Authorization Server)裡進行授權，授權完成後，授權伺服器 直接將 Access Token 返回給 前端應用，令牌儲存在前端頁面。
第二步：應用（純前端的應用）攜帶 訪問令牌(Access Token) 去訪問資源，獲取資源。
在整個過程中，雖然令牌是在前端URL中直接傳遞，但注意，令牌在HTTP協議中不是放在URL引數欄位中的，而是放在URL錨點裡。因為錨點資料不會被瀏覽器發到伺服器，因此有一定的安全保障。
-
使用者名稱密碼（Resource Owner Credentials）
這種方式最容易理解了，直接使用使用者的使用者名稱/密碼作為授權方式去訪問 授權伺服器，從而獲取Access Token，這個方式因為需要使用者給出自己的密碼，所以非常的不安全性。一般僅在客戶端應用與授權伺服器、資源伺服器是歸屬統一公司/團隊，互相非常信任的情況下采用。 -
客戶端憑證（Client Credentials）
這是適用於伺服器間通訊的場景。客戶端應用拿一個使用者憑證去找授權伺服器獲取Access Token。
以上，就是對微服務架構中「訪問安全」的一些思考。
在微服務架構的系列文章中，前面已經通過文章介紹過了「服務註冊 」、「服務閘道器 」、「配置中心 」、「 監控系統 」、「呼叫鏈監控」、「容錯隔離」，大家可以翻閱歷史文章檢視。
碼字不易啊，喜歡的話不妨轉發朋友，或點選文章右下角的“在看”吧。