image.png

JWT，英文全稱JSON Web Token，一種開(kāi)放行業(yè)標(biāo)準(zhǔn)。

應(yīng)用場(chǎng)景為單點(diǎn)登錄，API授權(quán)等。

假想的黑粉：“所以這篇文章是要詳細(xì)介紹JWT是什么嗎？”

非也非也，如果各位看官還不了解什么是JWT以及JWT的工作流程，還請(qǐng)自己先去GOOGLE下哈

我是不會(huì)跑題的，準(zhǔn)備愉快地進(jìn)入主題

JWT的優(yōu)點(diǎn)：用戶會(huì)話信息保存在客戶端，服務(wù)端再也不用操心用戶的會(huì)話信息，即服務(wù)端無(wú)狀態(tài)

JWT的缺點(diǎn)：只能被動(dòng)等到token過(guò)期，不能主動(dòng)失效token

假想的黑粉：“這個(gè)缺點(diǎn)有啥影響嗎？”

當(dāng)然啦，想想退出登錄，是不是就是一種主動(dòng)失效的應(yīng)用場(chǎng)景

假想的黑粉：“好像是，但這個(gè)容易解決啊，把token保存在后端服務(wù)，如redis，退出時(shí)在redis中把它干掉不就完事了嗎”<（￣︶￣）>

可以啊，腦袋轉(zhuǎn)得這么快，好像可以解決問(wèn)題

等等，好像哪里不對(duì)，這樣又把會(huì)話信息存放在服務(wù)端，JWT的優(yōu)勢(shì)木有了，那要它何用？用傳統(tǒng)的session方案就行了啊

簡(jiǎn)單講講服務(wù)端有狀態(tài)的傳統(tǒng)session方案：用戶登錄后，服務(wù)端把用戶會(huì)話信息存放在session中（保存在服務(wù)端的某個(gè)地方，例如緩存），然后把session ID存放于cookie中，后續(xù)用戶的請(qǐng)求中都會(huì)攜帶cookie，服務(wù)端通過(guò)cookie中的session ID即可判斷用戶的登錄狀態(tài)

假想的黑粉：“能解決問(wèn)題就行，那么糾結(jié)干嘛呢？”

這。。。不行不行，不能為了用而用啊

假想的黑粉：“那你有解決方案嗎？棄JWT而用session？”

我覺(jué)得吧，還是有使用的可能正確姿勢(shì)的，先來(lái)個(gè)華麗麗的分隔線

先來(lái)簡(jiǎn)單看一下JWT校驗(yàn)token的原理：

• 簽名：數(shù)據(jù) + 密鑰 => Hash

image.png

• 驗(yàn)證：數(shù)據(jù) + 密鑰 => hash => compare 攜帶的簽名

image.png

由上圖可見(jiàn)存放于服務(wù)端的密鑰只要不被竊取，數(shù)據(jù)就無(wú)法被篡改，一旦修改了數(shù)據(jù)，則compare步驟一定不通過(guò)，則該token無(wú)效

假想的黑粉：“哦，我知道了，那就篡改數(shù)據(jù)，token自動(dòng)就失效了”

你不是認(rèn)真的吧？在客戶端修改？Oh no！在服務(wù)端修改？Oh no！

假想的黑粉：“難道是修改密鑰？密鑰可是全局共用的哦，一經(jīng)修改，其它頒發(fā)的token也跟著失效，這可是災(zāi)難性的”

差不多猜對(duì)了，全局不行，那就不要全局，來(lái)個(gè)一一對(duì)應(yīng)， 一個(gè)用戶專屬一個(gè)唯一的密鑰。

當(dāng)要主動(dòng)失效A用戶的token，只要修改A用戶所對(duì)應(yīng)的密鑰即可，仔細(xì)想想，這個(gè)方案其實(shí)挺優(yōu)雅的，只是稍微修改了下密鑰的獲取方式，JWT的優(yōu)勢(shì)可以繼續(xù)發(fā)揮，我們來(lái)用下圖作個(gè)形象的理解吧

image.png

token驗(yàn)證流程比全局密鑰的模式多了一步：從Cache中取出某個(gè)用戶的密鑰。是否會(huì)對(duì)性能造成影響，就需要在實(shí)際的應(yīng)用場(chǎng)景中進(jìn)行評(píng)估了

好了，到此結(jié)束，謝謝觀看

假想的黑粉：“等等啊，我想問(wèn)續(xù)期怎么破啊，比如API授權(quán)續(xù)期問(wèn)題”

續(xù)期問(wèn)題可用：失效token，重新獲取新token的來(lái)解決

好的，真的要結(jié)束了，拜拜拜拜。。。