13權(quán)限認(rèn)證分布式session替代方案

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