微服務認證受權概覽

從單體架構向微服務架構轉型的過程當中，認證方式也發生了改變。

而轉變最大的方面即是有狀態向無狀態的轉變。

在單體架構時代，咱們通常使用的是會話管理(Session)，架構圖以下所示

即多實例採用一個同一個Session Store(通常採用Redis來存儲)來進行Session的管理，即共享Session,在第二代網關GateWay搭建流程 的SaveSession小節中有介紹共享Session的配置。對以上這種設置，咱們稱之爲有狀態。

而與之相對的就是無狀態，指的是服務器端不去記錄用戶的登陸狀態，再也不去維護用戶的Session。在微服務時代，若是依然採用共享Session的策略，則把各個獨立的微服務又捆綁在了Session Store中，若是Session Store掛了，則全部的微服務都沒法運行，等於把雞蛋放到了一個籃子中。而更主要的是若是Session Store須要作遷移，則全部的微服務地址都要調整，牽一髮而動全身。再就是若是Session Store達到了瓶頸(容量瓶頸，性能瓶頸)，都得對其進行擴容。

微服務的無狀態架構圖以下所示

服務器端不會存儲用戶的登陸狀態，而是在用戶登陸的時候頒發一個token,以後用戶的請求都須要帶上token(可能放在head中，可能放在url參數中),服務器端拿到token後進行解密，校驗token是否合法，有無過時，若是合法並無過時，就認爲用戶爲登陸狀態，不然爲未登陸狀態。咱們還能夠在Token裏面存儲一些不太敏感的用戶信息(好比用戶名),這樣服務器在解密完token之後就能夠直接使用。但有時候token裏不必定帶有用戶信息;而是利用token在某個地方查詢，才能得到用戶信息。好比在Spring OAuth2中能夠作以下設置，其中8002爲鑑權中心的端口。

security:
  oauth2:
    resource:
      user-info-uri: http://local.register.com:8002/user-me
      prefer-token-info: false

而後經過OAuth2.0經過token獲取受保護資源的解析 來拿取用戶的詳細信息。

有狀態和無狀態的優缺點

優缺點	有狀態	無狀態
優勢	服務器端控制力強	去中心化，無存儲，簡單，任意擴容，縮容
缺點	存在中心點，雞蛋在一個籃子裏，遷移麻煩，服務器端存儲數據，加大了服務器端壓力	服務器端控制力弱

無狀態登陸的實現和變種

• 到處安全

到處安全通常是指單點登陸，一次登陸能夠訪問全部的其餘的系統

咱們打開淘寶APP，首頁就會有天貓、聚划算等服務的連接，當你點擊之後就直接跳過去了，並無讓你再登陸一次

它的請求順序以下圖所示

通常這種方式採用OAuth 2.0來處理

• 外部無狀態，內部有狀態

該方式結合了Token和Session，通常用於舊單體系統和微服務過渡時使用

網關認證受權，內部裸奔

 

該形式的token認證解析都是由網關來處理的，解析後也能夠攜帶User_ID，UserName帶給後端的微服務，一切都是網關來決定用戶是誰，後端微服務無條件接受，這種形式對網關的安全要求比較高。

"內部裸奔"改進方案