從單體應用架構到分布式應用架構再到微服務架構，應用的安全訪問在不斷的經受考驗。為了適應架構的變化、需求的變化，身份認證與鑒權方案也在不斷的變革。面對數十個甚至上百個微服務之間的調用，如何保證高效安全的身份認證？面對外部的服務訪問，該如何提供細粒度的鑒權方案。
單體應用 VS 微服務
隨着微服務的興起，傳統的單體應用下的身份認證和鑒權面臨的挑戰也越來越大。為了適應架構的變化，需求的變化，身份認證和鑒權方案也在不斷的升級改革。在單體應用體系下，應用是一個整體，一般針對所有的請求都會進行權限校驗。請求一般會通過一個權限的攔截器進行權限的校驗，在登錄時將用戶的信息緩存到 session 中，后續訪問則從緩存中獲取用戶信息。
而微服務架構下，一個應用會被拆分成若干個微應用，每個微應用都需要對訪問鑒權，每個微應用都需要明確當前訪問用戶及其權限。尤其當訪問來源不只是瀏覽器，還包括其它服務的調用時，單體應用架構下的鑒權方式就不是特別適合了。在微服務架構下，要考慮外部應用接入的場景、用戶-服務的鑒權、服務-服務的鑒權等多種鑒權場景。
單點登錄
這意味着每個面向用戶的服務都必須與認證服務交互，這回產生大量非常瑣碎的網絡流量和重復的工作，當動輒數十個微應用時，這種方案的弊端會更加明顯。
分布式 Session 方案
分布式會話方案原理主要是將關於用戶認證的信息存儲在共享存儲中，且通常由用戶會話作為 key 來實現的簡單的分布式哈希映射。當用戶訪問微服務時，用戶數據可以從共享存儲中獲取。在某些場景下，這種方案很不錯，用戶登錄狀態是不透明的。同事也是一個高可用且可擴展的解決方案。這種方案的缺點在於共享存儲需要一定的保護機制，因此需要通過安全連接來訪問，這種解決方案實現就通常具有相當高的復雜性。
客戶端 Token 方案
令牌在客戶端生成，由身份驗證服務進行簽名，並且必須包含足夠的信息，以便可以在所有微服務中建立用戶身份。令牌會附加到每個請求上，為微服務提供用戶身份驗證，這種解決方案的安全性相對較好，但身份驗證注銷是一個大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等。對於客戶端令牌的編碼方案，Borsos 更喜歡使用 JSON Web Token（JWT），它足夠簡單且庫支持程度也比較好。
客戶端 Token 與 API 網關結合
這個方案意味着所有的請求都要通過網關，從而有效的隱藏了微服務。在請求時，網關將原始用戶令牌轉化為內部會話 ID 令牌。在這種情況下，注銷就不是問題，因為可以在注銷時撤銷用戶的令牌。
來自：微信公眾號 EAWorld