答：通常存儲在客戶端里。

jwt 即 JSON Web Token，是一種認(rèn)證協(xié)議，一般用來校驗(yàn)請求的身份信息和身份權(quán)限。

早上逛某乎的時候，遇到一位同學(xué)在問這個問題，很好奇jwt的存儲位置。剛好前段時間在學(xué)習(xí)此內(nèi)容，不請自邀，厚顏強(qiáng)答。
最開始我也很好奇這個token怎么保存，還差點(diǎn)想搞個redis存儲這個token。

后來查閱資料才知道，原來這個token，服務(wù)端是可以不保存的。只需要客戶端保存好就行，無論什么保持方式，甚至你讓用戶寫紙條揣兜里都可以！

那這個token是怎么工作的呢？

先來說說需要服務(wù)端存儲的操作，即傳統(tǒng)的session會話的做法。

首先要做用戶登陸，先要在服務(wù)端維護(hù)一個登陸表，這個登陸表可以放在緩存里，也可以放進(jìn)數(shù)據(jù)庫里。
當(dāng)用戶登陸的時候，把用戶信息寫入這個登陸表，然后導(dǎo)出一個登陸id，也就是所謂的session，把這個session返回給客戶的，讓客戶端下次請求把這個信息帶上來。

對于前端的小伙伴來說，這個過程通常無感知，后端的老哥們使用一個叫set-cookie的http頭字段，自己把數(shù)據(jù)寫入瀏覽器cookie里了。然后請求的時候，瀏覽器又會自己把cookie寫進(jìn)請求頭里面。

當(dāng)客戶端請求進(jìn)入服務(wù)端時，服務(wù)端拿到cookie里面的session，然后到登陸表里面去查用戶信息，校驗(yàn)用戶權(quán)限，然后即可完成正常的業(yè)務(wù)交互。

誒，那現(xiàn)在我因?yàn)楦鞣N亂七八糟的原因，不想維護(hù)一個登錄表了，想想要怎么搞？
簡單呀，直接把用戶信息發(fā)給客戶端，讓客戶端每次把用戶信息都帶過來，這樣請求一進(jìn)來，連表都不用查，直接就知道是哪個用戶在請求。

但是這樣子，用戶的信息都曝光了，那些中間人呀，最喜歡這種耿直請求了，他們直接拿個凳子坐在你服務(wù)器端口，坐個幾天，你數(shù)據(jù)庫里的全家老表就被別人扒個清清楚楚。

這樣肯定不行，那怎么辦？

加個密再混個淆唄，這樣老哥們拿到你的token，一時半會也一臉懵逼，大概率會大大咧咧地走了，只留下少部分有備（KPI）而來的老哥在苦苦尋求破解。

而你在服務(wù)端一解密，你就拿到用戶信息了，同樣的，你把過期時間也寫進(jìn)密文里面，遇到過期就401跳登錄頁。這樣，一個不需要后端存儲登錄憑證的方案就出爐咯。

這就是jwt最基本的工作原理：就是把身份信息交給客戶端保管。

jwt生成的token由header、payload、signature三部分組成，這三個部分用小數(shù)點(diǎn)“.”分隔開。

header，也就是頭部信息，是描述這個token基本信息，是一個json格式：

{
    "alg":"HS256",
    "typ":"JWT"
}

alg代表的是后面signature簽名部分的生成加密算法，typ表示該token是jwt類型。

payload，就是你的那些用戶數(shù)據(jù)啦，也是一個json格式。不過jwt不建議將敏感數(shù)據(jù)放進(jìn)里面，因?yàn)橐?guī)范里，payload和header一樣，僅僅只是做一次base64編碼后顯示在token上。

signature，是這個token的簽名，通常情況下是將前面的header和payload加上一個你自己定義的私鑰字符串一起加密生成的字符串。

因?yàn)榍懊嬲f了，jwt僅僅是將payload的內(nèi)容做一次base64編碼，所以那些攻擊者老哥要改你的內(nèi)容還是很簡單的，但是老哥們不知道你的私鑰啊，改了之后沒法生成正確的簽名，用加密的方式再次對請求進(jìn)來的header.payload進(jìn)行校驗(yàn)，發(fā)現(xiàn)跟signature對不上，這時候你就可以很清楚知道，有人在搞事情，直接返回個500假裝服務(wù)器掛了。
如果想更安全，建議全程使用https協(xié)議進(jìn)行請求通信。

當(dāng)然，你已經(jīng)了解了這個工作原理，自己搞一套惡心人的規(guī)范，也不是不行，比如，把payload再加一次密然后gzip下等等。

那，采用jwt的好處都有啥？

第一點(diǎn)，自然是服務(wù)端不需要維護(hù)一個登陸表了，節(jié)省空間，特別是用戶多的情況。
第二點(diǎn)，拓展簡單，前提是你不搞事情，老老實(shí)實(shí)遵守采用json格式去表述你的內(nèi)容。
第三點(diǎn)，無狀態(tài)，只要服務(wù)端支持解析，就可以開展業(yè)務(wù)，不需要專門搞個機(jī)制去共享session，方便加機(jī)子。
第四點(diǎn)，支持各種各樣的客戶端，不支持cookie也能玩。
壞處嘛，自然就是每次請求都要把這些數(shù)據(jù)帶來帶去的，肯定是增加了請求內(nèi)容的。而且，每次請求進(jìn)來你都要去校驗(yàn)，去拿header和paylaod加一次密與signature校驗(yàn)，也會增加請求的處理時間。這個與傳統(tǒng)操作相比，其實(shí)是一個時間與空間之間的權(quán)衡問題，最后，還是看你選擇咯。

到此這篇關(guān)于淺談node使用jwt生成的token應(yīng)該存在哪里的文章就介紹到這了,更多相關(guān)jwt生成的token存哪里內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！ 

最新評論