淺談node使用jwt生成的token應該存在哪里

答：通常存儲在客戶(hù)端里。

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

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

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

那這個(gè)token是怎么工作的呢？

先來(lái)說(shuō)說(shuō)需要服務(wù)端存儲的操作，即傳統的session會(huì )話(huà)的做法。

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

對于前端的小伙伴來(lái)說(shuō)，這個(gè)過(guò)程通常無(wú)感知，后端的老哥們使用一個(gè)叫set-cookie的http頭字段，自己把數據寫(xiě)入瀏覽器cookie里了。然后請求的時(shí)候，瀏覽器又會(huì )自己把cookie寫(xiě)進(jìn)請求頭里面。

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

誒，那現在我因為各種亂七八糟的原因，不想維護一個(gè)登錄表了，想想要怎么搞？
簡(jiǎn)單呀，直接把用戶(hù)信息發(fā)給客戶(hù)端，讓客戶(hù)端每次把用戶(hù)信息都帶過(guò)來(lái)，這樣請求一進(jìn)來(lái)，連表都不用查，直接就知道是哪個(gè)用戶(hù)在請求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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