目錄
一、前言
二、單體應用認證和鑑權
三、微服務認證和鑑權
1、面臨的問題
2、使用者身份認證
3、使用者狀態保持
4、實現單點登入
5、使用者許可權控制
6、微服務之間的認證與鑑權
7、第三方應用
四、總結
我們知道微服務技術或微服務架構是一把雙刃劍，其給我們帶來了簡單、靈活的部署，聚焦、專注快速迭代，低耦合、高內聚、易擴充套件等優勢；與此同時，也引入了更加複雜的問題。本文要著重闡述的如何在微服務架構中實現乙個安全、高效的認證和鑑權方案。
我們先回想下，在單體應用架構時我們是怎麼對使用者進行認證和鑑別許可權的？在單體架構下，往往會採用乙個安全模組來實現使用者認證和鑑權。
3.1 面臨的問題
在微服務架構中，我們知道微服務的粒度切分以業務邊界為依據的。乙個龐大的系統中，根據業務會劃分出很多的微服務。對每乙個微服務的訪問請求都需要進行認證和鑑權，微服務的認證和鑑權又面臨哪些問題？
微服務架構下的認證和鑑權涉及到場景更為複雜，涉及到使用者訪問微服務應用，第三方應用訪問微服務應用，微服務之間相互訪問等多種場景，每種場景下的認證和鑑權方案都需要考慮到，如何來保證複雜場景下微服務的安全性？
認證和鑑權邏輯，在微服務架構中放在什麼位置、哪一層，更為合適？
認證和鑑權成功後的資訊如何儲存，如何維護呼叫方和服務方之間的認證關係？
微服務應用的許可權粒度，如何做到api級別的控制？
3.2 技術方案
3.2.1 使用者身份認證
在微服務體系架構中，微服務應用是由多個相互獨立的微服務程序組成的，對每個微服務的訪問都需要進行使用者認證。
微服務應用應遵循單一職責原理，即乙個微服務只處理單一的業務邏輯。認證和鑑權的公共邏輯不應該放到微服務實現中。因此需要考慮乙個抽象、公共的邏輯對使用者進行身份認證和鑑權服務。由於在微服務架構中以api gateway作為對外提供服務的入口，因此可以考慮在api gateway處提供統一的使用者認證。具體就技術實現採用zuul+spring security+oauth2/jwt。
3.2.2 使用者狀態保持
在單體應用時，我們是在伺服器端採用session和客戶端採用cookie來儲存使用者狀態，由於在伺服器是有狀態的，對伺服器的水平擴充套件有影響。
我們知道微服務架構的優勢之一是微服務的水平擴充套件(scalability)和彈性(resiliency)，所以微服務最好是無狀態的。因此建議採用token來記錄使用者登入狀態。
token和seesion主要的不同點是儲存的地方不同。
session是集中儲存在伺服器中的；而token是使用者自己持有的，一般以cookie的形式儲存在瀏覽器中。token中儲存了使用者的身份資訊，每次請求都會傳送給gateway，因此可以判斷訪問者的身份，並判斷其對請求的資源有沒有訪問許可權。
token用於表明使用者身份，其又以cookie的形式儲存在瀏覽器中。為了保障資訊的安全，因此需要對其內容進行加密，避免被請求方或者第三者篡改。
jwt(json web token)是乙個定義token格式的開放標準(rfc 7519)，定義了token的內容、加密方式並提供了各種語言的lib。
jwt token的結構非常簡單，包括三部分：
authorization: bearer 37mf-90b5f-86jqm使用者輸入使用者名稱,密碼等驗證資訊，向伺服器發起登入請求
伺服器端驗證使用者登入資訊，生成jwt token
伺服器端將token返回給客戶端，客戶端儲存在本地（一般以cookie的方式儲存）
客戶端向伺服器端傳送訪問請求，請求中攜帶之前頒發的token
伺服器端驗證token，確認使用者的身份和對資源的訪問許可權，並進行相應的處理（拒絕或者允許訪問）
token儲存在cookie中，這樣客戶端登出時，自然可以清空掉
將token存放到分布式快取中，每次校驗token時區檢查下該token是否已登出。不過這樣也就失去了快速校驗token的優點。
多採用短期令牌，比如令牌有效期是30分鐘，這樣可以一定程度上降低登出後 token可用性的風險。
3.2.3 單點登入
我們看下維基百科中，對單點登入的解釋。
單點登入（英語：single sign-on，縮寫為 sso），又譯為單一簽入，一種對於許多相互關連，但是又是各自獨立的軟體系統，提供訪問控制的屬性。當擁有這項屬性時，當使用者登入時，就可以獲取所有系統的訪問許可權，不用對每個單一系統都逐一登入。相同的，單一登出（single sign-off）就是指，只需要單一的登出動作，就可以結束對於多個系統的訪問許可權。在微服務架構中，單點登入可以理解為當使用者登入成功後，就可以訪問所有有許可權訪問的微服務。api gateway提供了客戶端訪問微服務的入口，token實現了無狀態的使用者認證。結合這兩種技術，我們就可以為微服務應用實現乙個單點登入方案。
微服務單點登入流程下，使用者的認證和鑑權如下圖：
客戶端傳送登入請求到api gateway
api gateway將登入請求**到security service
security service驗證使用者身份，並頒發token
客戶端請求傳送到api gateway
api gateway呼叫的security service對請求中的token進行驗證，檢查使用者的身份
如果請求中沒有token，token過期或者token驗證非法，則拒絕使用者請求。
security service檢查使用者是否具有該操作權
如果使用者具有該操作許可權，則把請求傳送到後端的business service，否則拒絕使用者請求。
3.2.4 使用者許可權控制
api gateway處進行統一的許可權控制
客戶端傳送的http請求中包含有請求的resource及http method。如果系統遵循rest規範，以uri資源方式對訪問物件進行建模，則api gateway可以從請求中直接擷取到訪問的資源及需要進行的操作，然後呼叫security service進行許可權判斷，根據判斷結果決定使用者是否有許可權對該資源進行操作，並**到後端的business service。這種實現方式api gateway處統一處理認證和鑑權邏輯，各個微服務不需要考慮使用者認證和鑑權，只需要處理業務邏輯，簡化了各微服務的實現。
3.2.5 微服務之間的認證
微服務應用，除了來自使用者和第三方的訪問外，還有大量的微服務之間訪問。根據微服務應用的資料敏感程度的不同，對於微服務之間的相互訪問可能有不同的安全要求。
微服務提供的資料敏感程度不是很高
在這種情況下，一旦攻擊者侵入到內部網路後沒有了保護措施。雖然微服務的資料敏感程度不高，但是攻擊行為仍然給我們帶來危害。
istio security architecture
3.2.6 第三方應用
oauth2
oauth2針對不同場景有不同的認證流程，乙個典型的認證流程如下圖所示：
（**於網路）
使用者向oauth客戶端程式發起乙個請求，oauth客戶端程式在處理該請求時發現需要訪問使用者在資源伺服器中的資料。
客戶端程式將使用者請求重定向到認證伺服器，該請求中包含乙個callback的url。
認證伺服器返回授權頁面，要求使用者對oauth客戶端的資源請求進行授權。
使用者對該操作進行授權後，認證伺服器將請求重定向到客戶端程式的callback url，將授權碼返回給客戶端程式。
客戶端程式將授權碼傳送給認證伺服器，請求token。
認證伺服器驗證授權碼後將token頒發給客戶端程式。
客戶端程式採用頒發的token訪問資源，完成使用者請求。
（引用：
微服務架構下，認證和鑑權涉及到場景複雜，涉及到使用者訪問微服務應用，第三方應用訪問微服務應用，微服務之間相互訪問等多種場景。
許可權建模時，往往會拆分成功能許可權和資料許可權。上述的解決方案，從功能許可權結合各種微服務應用場景下，抽象了身份認證和許可權驗證模型。
-eof-
微服務簡介 構建單體應用
網際網路技術發展迅速的今天，微服務倍受關注 文章 部落格 社交 討論和會議演講都在談論。與此同時，也有持懷疑態度的軟體社群人員認為微服務沒什麼新鮮可言。反對者聲稱它的思想只是面向服務架構的重塑。然而，無論是炒作還是懷疑，不可否認，微服務架構模式具有非常明顯的優勢 特別是在實施敏捷開發和複雜的企業應用...
如何保障微服務安全
原文 securing microservices摘要 如何保護微服務，確保微服務的安全，作者從保護應用程式安全和保護容器的安全兩個方面進行了闡述，以下是譯文 實現乙個微服務很難。部署乙個微服務應用程式複雜性也很高。保護微服務的安全就更難更複雜。從 開始呢？腦海中首先出現的一些詞是身份驗證和授權 防...
GO語言 微服務簡介 構建單體應用
網際網路技術發展迅速的今天，微服務倍受關注 文章 部落格 社交 討論和會議演講都在談論。與此同時，也有持懷疑態度的軟體社群人員認為微服務沒什麼新鮮可言。反對者聲稱它的思想只是面向服務架構的重塑。然而，無論是炒作還是懷疑，不可否認，微服務架構模式具有非常明顯的優勢 特別是在實施敏捷開發和複雜的企業應用...