13權限認證分布式session替代方案

sessionsession復制的方法來說，綁定IP的方式有更明顯的缺陷：IP的情況下無法在網(wǎng)關層應用負載均衡策略，而且某個服務器出現(xiàn)故障的話會對指定IP段的來訪用戶產(chǎn)生較大影響。對網(wǎng)關層IPIP，這就會導致更換IP后的session為了解決第二個問題，可以通過一致性HashID做Hash，不同的HashIP切Redis這個方案解決了前面提到的大部分問題，session不再保存在服務器上，取而代之的是保存在redis中，所有的服務器都向redis寫入/讀取緩存信息。在Tomcat層面，我們可以直接引入tomcat-redis-session-manager組件，將容器層面sessionredis的組件，但是這種方案和容器綁定的比較緊密。另一個更優(yōu)雅的方案是借助spring-sessionredissession，盡管這個方案脫離了具體Session的用戶鑒權方案，這類Session方案已經(jīng)在微服務應用中被Tothinkoutofboxguys~session個鑒權方案-OAuth2.0。OAuth2.0是一個開放授權標準協(xié)議，它允許用戶讓第三方應用訪問該用戶在某服務的特個第三方應用，我們通過OAuth2.0AuthGrant在這一步Client發(fā)起AuthorizationRequest（比如通過微信內掃碼授權AuthGetToken客戶端拿著從微信獲取到的AuthGrant，發(fā)給第三方引用的鑒權服務，換取一個Token，這個Token就是訪問第三方應用資源所需Token令牌，服務組件搭建OAuth2.0的鑒權服務，OAuth2.0的協(xié)議還涉及到很多復雜的規(guī)范，比如角來看另外一個更輕量級的授權方案：JWT鑒權。JWT的基本思想就是通過用戶名+密碼換取一個AccessToken。用戶名+密碼訪問鑒權服務驗證通過：服務器返回一個Access給客戶端，并將token保存在服務端某個地方用于后面的訪問控制（可以保存在數(shù)據(jù)庫或者Redis中）驗證失敗：不生成JWTAccessToken由三個部分構成，分別是Header、PayloadSignature，我們分Header頭部聲明了Token的類型（JWT類型）{'typ':'alg':}Payload這一段包含的信息相當豐富，你可以定義Token收到Token的時候也同樣可以對Payload中包含的信息做驗證，比如說某個Token的簽發(fā)者是“Feign-API”，假如某個接口只能允許“Gateway-API”簽發(fā)的Token，那么在做鑒權服務時就可以加入Issuer的判斷邏輯。SignatureHeader和Payload以及一個密鑰用來生成簽證信息，這一步會使用Header里我們指定的加密算法進行加密實現(xiàn)的依賴項到項目中的po