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

jwt 即 ON Web Token，是一種認證協議，一般用來校驗請求的身份資訊和身份許可權。

早上逛某乎的時候，遇到一位同學在問這個問題，很好奇jwt的儲存位置。剛好前段時間在學習此內容，不請自邀，厚顏強答。
最開始我也很好奇這個token怎麼儲存，還差點想搞個redis儲存這個token。

後來查閱資料才知道，原來這個token，服務端是可以不儲存的。只需要客戶端儲存好就行，無論什麼保持方式，甚至你讓使用者寫紙條揣兜裡都可以！

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

先來說說需要服務端儲存的操作，即傳統的session會話的做法。

首先要做使用者登陸，先要在服務端維護一個登陸表，這個登陸表可以放在快取裡，也可以放進裡。

對於前端的小夥伴來說，這個過程通常無感知，後端的老哥們使用一個叫set-cookie的http頭欄位，自己把資料寫入瀏覽器cookie裡了。然後請求的時候，瀏覽器又會自己把cookie寫進請求頭裡面。

當客戶端請求進入服務端時，服務端拿到cookie裡面的session，然後到登陸表裡面去查使用者資訊，校驗使用者權yOMVFRWCW限，然後即可完成正常的業務互動。

誒，那現在我因為各種亂七八糟的原因，不想維護一個登入表了，想想要怎麼搞？

但是這樣子，使用者的資訊都曝光了，那些中間人呀，最喜歡這種耿直請求了，他們直接拿個凳子坐在你伺服器埠，坐個幾天，你資料庫裡的全家老表就被別人扒個清清楚楚。

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

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

而你在服務端一解密，你就拿到使用者資訊了，同樣的，你把過期時間也寫進密文裡面，遇到過期就401跳登入頁。這樣，一個不需要後端儲存登入憑證的方案就出爐咯。

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

jwt生成的token由header、payload、signature三部分組成，這三個部分用小數點“.”分隔開。

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

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

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

payload，就是你的那些使用者資料啦，也是一個json格式。不過jwt不建議將敏感資料放進裡面，因為規範裡，payload和header一樣，僅僅只是做一次base64編碼後顯示在token上。

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

因為前面說了，jwt僅僅是將payload的內容做一次base64編碼，所以那些攻擊者老哥要改你的內容還是很簡單的，但是老哥們不知道你的私鑰啊，改了之後沒法生成正確的簽名，用加密的方式再次對請求進來的header.payload進行校驗，發現跟signature對不上，這時候你就可以很清楚知道，有人在搞事情，直接返回個500假裝伺服器掛了。
如果想更安全，建議全程使用https協議進行請求通訊。

當然，你已經瞭解了這個http://www.cppcns.com工作原理，自己搞一套噁心人的規範，也不是不行，比如，把payload再加一次密然後gzip下等等。

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

第一點，自然是服務端不需要維護一個登陸表了，節省空間，特別是使用者多的情況。
第二點，拓展簡單，前提是你不搞事情，老老實實遵守採用json格式去表述你的內容。
第三點，無狀態，只要服務端支援解析，就可以開展業務，不需要專門搞個機制去共享session，方便加機子。
第四點，支援各種各樣的客戶端，不支援cookie也能玩。
壞處嘛，自然就是每次請求都要把這些資料帶來帶去的，肯定是增加了請求內容的。而且，每次請求進來你都要去校驗，去拿header和paylaod加一次密與signature校驗，也會增加請求的處理時間。這個與傳統操作相比，其實是一個時間與空間之間的權衡問題，最後，還是看你選擇咯。

到此這篇關於淺談node使用jwt生成的token應該存在哪裡的文章就介紹到這了,更多相關jwt生成的token存哪裡內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！