整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
essionStorage只能保存在單一的瀏覽器窗口或分頁(tab), 關(guān)閉瀏覽器后存儲的數(shù)據(jù)就消失了, 其最大的用途在于保存一些臨時的數(shù)據(jù), 防止用戶重新整理
網(wǎng)頁時不小心丟失這些數(shù)據(jù)。sessionStorage的操作方法與localStorage相同;
1 存儲
window.sessionStorage.setItem("userdata","Hello HTML5");
window.sessionStorage["userdata"]="Hello HTML5";
window.sessionStorage.userdata="Hello HTML5";2 讀取
var value1=window.sessionStorage.getItem("userdata");
var value1=window.sessionStorage["userdata"];
var value1=window.sessionStorage.userdata;3 清除
window.sessionStorage.removeItem("userdata");
delete window.sessionStorage.userdata;
delete window.sessionStorage["userdata"];//全部清除
sessionStorage.clear();session聲明周期包括刷新網(wǎng)頁的頁面
文分享自華為云社區(qū)《Cookie、Session、Token 背后的故事-云社區(qū)-華為云》，作者： 龍哥手記。
作為網(wǎng)友的我們，每天都會使用瀏覽器來逛各種網(wǎng)站，來滿足日常的工作生活需求。
現(xiàn)在的交互體驗還是很絲滑的，但早期并非如此，而是一錘子買賣。
無狀態(tài)的 HTTP 協(xié)議是什么鬼？
HTTP 無狀態(tài)協(xié)議，是指協(xié)議對于業(yè)務(wù)處理沒有記憶能力，之前做了啥完全記不住。每次請求都是完全獨立互不影響的，沒有任何上下文信息。
缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳關(guān)鍵信息，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。
如果大家沒明白，可以想一下《夏洛特?zé)馈防锩娴臉蚨危?/p>
大概明白了吧，假如一直用這種原生無狀態(tài)的 HTTP 協(xié)議，我們每換一個頁面可能就得重新登錄一次，那還玩?zhèn)€球。
所以必須要解決 HTTP 協(xié)議的無狀態(tài)，提升網(wǎng)站的交互體驗，否則星辰大海是去不了的。
整個事情交互的雙方只有客戶端和服務(wù)端，所以必然要在這兩個當(dāng)事者身上下手。
客戶端來買單
客戶端每次請求時把自己必要的信息封裝發(fā)送給服務(wù)端，服務(wù)端查收處理一下就行。
服務(wù)端來買單
客戶端第一次請求之后，服務(wù)端就開始做記錄，然后客戶端在后續(xù)請求中只需要將最基本最少的信息發(fā)過來就行，不需要太多信息了。
Cookie 總是保存在客戶端中。按在客戶端中的存儲位置，可分為內(nèi)存 Cookie 和硬盤Cookie。
內(nèi)存 Cookie 由瀏覽器維護(hù)，保存在內(nèi)存中，瀏覽器關(guān)閉后就消失了，其存在時間是短暫的。硬盤 Cookie 保存在硬盤里，有一個過期時間。除非用戶手工清理或到了過期時間，硬盤Cookie不會被刪除，其存在時間是長期的。
HTTP Cookie（也叫 Web Cookie 或瀏覽器 Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)。它會在瀏覽器下次向同一服務(wù)器再發(fā)起請求時，被攜帶并發(fā)送到服務(wù)器上。
通常 Cookie 用于告知服務(wù)端兩個請求是否來自同一瀏覽器，如保持用戶的登錄狀態(tài)。Cookie 使基于無狀態(tài)的HTTP協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。
Cookie 主要用于以下三個方面：
當(dāng)服務(wù)器收到 HTTP 請求時，服務(wù)器可以在響應(yīng)頭里面添加一個 Set-Cookie 選項。
瀏覽器收到響應(yīng)后通常會保存下 Cookie，之后對該服務(wù)器每一次請求中都通過 Cookie 請求頭部將 Cookie 信息發(fā)送給服務(wù)器。另外，Cookie 的過期時間、域、路徑、有效期、適用站點都可以根據(jù)需要來指定。
服務(wù)器使用 Set-Cookie 響應(yīng)頭部向用戶瀏覽器發(fā)送 Cookie信息。
一個簡單的 Cookie 可能像這樣：
Set-Cookie: <cookie名>=<cookie值>
HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry客戶端對該服務(wù)器發(fā)起的每一次新請求，瀏覽器都會將之前保存的Cookie信息通過 Cookie 請求頭部再發(fā)送給服務(wù)器。
GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry我來訪問下淘寶網(wǎng)，抓個包看看這個真實的過程：
Cookie 常用來標(biāo)記用戶或授權(quán)會話，被瀏覽器發(fā)出之后可能被劫持，被用于非法行為，可能導(dǎo)致授權(quán)用戶的會話受到攻擊，因此存在安全問題。
還有一種情況就是跨站請求偽造 CSRF，簡單來說 比如你在登錄銀行網(wǎng)站的同時，登錄了一個釣魚網(wǎng)站，在釣魚網(wǎng)站進(jìn)行某些操作時可能會獲取銀行網(wǎng)站相關(guān)的Cookie信息，向銀行網(wǎng)站發(fā)起轉(zhuǎn)賬等非法行為。
跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當(dāng)前已登錄的 Web 應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。跟跨網(wǎng)站腳本（XSS）相比，XSS 利用的是用戶對指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任。
跨站請求攻擊，簡單地說，是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認(rèn)證過的網(wǎng)站并運(yùn)行一些操作（如發(fā)郵件，發(fā)消息，甚至財產(chǎn)操作如轉(zhuǎn)賬和購買商品）。
由于瀏覽器曾經(jīng)認(rèn)證過，所以被訪問的網(wǎng)站會認(rèn)為是真正的用戶操作而去運(yùn)行。這利用了 Web 中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發(fā)出的。
不過這種情況有很多解決方法，特別對于銀行這類金融性質(zhì)的站點，用戶的任何敏感操作都需要確認(rèn)，并且敏感信息的 Cookie 只能擁有較短的生命周期。
同時 Cookie 有容量和數(shù)量的限制，每次都要發(fā)送很多信息帶來額外的流量消耗、復(fù)雜的行為 Cookie 無法滿足要求。
特別注意：以上存在的問題只是 Cookie 被用于實現(xiàn)交互狀態(tài)時存在的問題，但并不是說 Cookie 本身的問題。
試想一下：菜刀可以用來做菜，也可以被用來從事某些暴力行為，你能說菜刀應(yīng)該被廢除嗎？
如果說 Cookie 是客戶端行為，那么 Session 就是服務(wù)端行為。
Cookie 機(jī)制在最初和服務(wù)端完成交互后，保持狀態(tài)所需的信息都將存儲在客戶端，后續(xù)直接讀取發(fā)送給服務(wù)端進(jìn)行交互。
Session 代表服務(wù)器與瀏覽器的一次會話過程，并且完全由服務(wù)端掌控，實現(xiàn)分配ID、會話信息存儲、會話檢索等功能。
Session 機(jī)制將用戶的所有活動信息、上下文信息、登錄信息等都存儲在服務(wù)端，只是生成一個唯一標(biāo)識 ID 發(fā)送給客戶端，后續(xù)的交互將沒有重復(fù)的用戶信息傳輸，取而代之的是唯一標(biāo)識 ID，暫且稱之為 Session-ID 吧。
首先明確一點，Session 和 Cookie 沒有直接的關(guān)系。可以認(rèn)為 Cookie 只是實現(xiàn) Session 機(jī)制的一種方法途徑而已，沒有 Cookie 還可以用別的方法。
Session和Cookie的關(guān)系就像加班和加班費的關(guān)系，看似關(guān)系很密切，實際上沒啥關(guān)系。
Session 的實現(xiàn)主要兩種方式：Cookie 與 URL 重寫，而 Cookie 是首選方式。因為各種現(xiàn)代瀏覽器都默認(rèn)開通 Cookie 功能，但是每種瀏覽器也都有允許 Cookie 失效的設(shè)置，因此對于 Session 機(jī)制來說還需要一個備胎。
將會話標(biāo)識號以參數(shù)形式附加在超鏈接的URL地址后面的技術(shù)稱為 URL 重寫
原始 URL：
http://taobao.com/getitem?name=baymax&action=buy重寫后的 URL:
http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy由于 Session 信息是存儲在服務(wù)端的，因此如果用戶量很大的場景，Session 信息占用的空間就不容忽視。
對于大型網(wǎng)站必然是集群化&分布式的服務(wù)器配置。如果 Session 信息是存儲在本地的，那么由于負(fù)載均衡的作用，原來請求機(jī)器 A 并且存儲了 Session 信息，下一次請求可能到了機(jī)器 B，此時機(jī)器 B 上并沒有 Session 信息。
這種情況下要么在 B 機(jī)器重復(fù)創(chuàng)建造成浪費，要么引入高可用的 Session 集群方案，引入 Session 代理實現(xiàn)信息共享，要么實現(xiàn)定制化哈希到集群 A，這樣做其實就有些復(fù)雜了
Token 是令牌的意思，由服務(wù)端生成并發(fā)放給客戶端，是一種具有時效性的驗證身份的手段。
Token 避免了 Session 機(jī)制帶來的海量信息存儲問題，也避免了 Cookie 機(jī)制的一些安全性問題，在現(xiàn)代移動互聯(lián)網(wǎng)場景、跨域訪問等場景有廣泛的用途。
以 JSON Web Token（JWT）為例，Token主要由三部分組成：
header 和 payload 的信息不做加密，只做一般的 base64 編碼。服務(wù)端收到 token 后剝離出 header 和 payload 獲取算法、用戶、過期時間等信息，然后根據(jù)自己的加密密鑰來生成 sign，并與客戶端傳來的 sign 進(jìn)行一致性對比，來確定客戶端的身份合法性。
這樣就實現(xiàn)了用 CPU 加解密的時間換取存儲空間，同時服務(wù)端密鑰的重要性就顯而易見，一旦泄露整個機(jī)制就崩塌了，這個時候就需要考慮 HTTPS 了。
Cookie、Session、Token 這三者是不同發(fā)展階段的產(chǎn)物，并且各有優(yōu)缺點，三者也沒有明顯的對立關(guān)系，反而常常結(jié)伴出現(xiàn)，這也是容易被混淆的原因。
Cookie 側(cè)重于信息的存儲，主要是客戶端行為。Session 和 Token 側(cè)重于身份驗證，主要是服務(wù)端行為。
三者方案在很多場景都還有生命力，了解場景才能選擇合適的方案。
點擊下方，第一時間了解華為云新鮮技術(shù)~
華為云博客_大數(shù)據(jù)博客_AI博客_云計算博客_開發(fā)者中心-華為云
認(rèn)證和授權(quán)，其實吧簡單來說就是:認(rèn)證就是讓服務(wù)器知道你是誰，授權(quán)就是服務(wù)器讓你知道你什么能干，什么不能干，認(rèn)證授權(quán)倆種方式：Session-Cookie與JWT，下面我們就針對這兩種方案就行闡述。
當(dāng) client通過用戶名密碼請求server并通過身份認(rèn)證后，server就會生成身份認(rèn)證相關(guān)的 session 數(shù)據(jù)，并且保存在內(nèi)存或者內(nèi)存數(shù)據(jù)庫。并將對應(yīng)的 sesssion_id返回給client，client會把保存session_id（可以加密簽名下防止篡改）在cookie。此后client的所有請求都會附帶該session_id（畢竟默認(rèn)會把cookie傳給server），以確定server是否存在對應(yīng)的session數(shù)據(jù)以及檢驗登錄狀態(tài)以及擁有什么權(quán)限，如果通過校驗就該干嘛干嘛，否則重新登錄。
前端退出的話就清cookie。后端強(qiáng)制前端重新認(rèn)證的話就清或者修改session。
相比JWT，最大的優(yōu)勢就在于可以主動清除session了
session保存在服務(wù)器端，相對較為安全
結(jié)合cookie使用，較為靈活，兼容性較好
cookie + session在跨域場景表現(xiàn)并不好
如果是分布式部署，需要做多機(jī)共享session機(jī)制，實現(xiàn)方法可將session存儲到數(shù)據(jù)庫中或者redis中
基于 cookie 的機(jī)制很容易被 CSRF
查詢session信息可能會有數(shù)據(jù)庫查詢操作
session: 主要存放在服務(wù)器端，相對安全
cookie: 可設(shè)置有效時間，默認(rèn)是關(guān)閉瀏覽器后失效，主要存放在客戶端，并且不是很安全，可存儲大小約為4kb
sessionStorage: 僅在當(dāng)前會話下有效，關(guān)閉頁面或瀏覽器后被清除
localstorage: 除非被清除，否則永久保存
JSON Web Token（JWT）是一種開放標(biāo)準(zhǔn)（RFC 7519），它定義了一種緊湊且獨立的方式，可以將各方之間的信息作為JSON對象進(jìn)行安全傳輸。該信息可以驗證和信任，因為是經(jīng)過數(shù)字簽名的。
JWT基本上由.分隔的三部分組成，分別是頭部，有效載荷和簽名。 一個簡單的JWT的例子，如下所示：
eyJhbGciOiJIUzI1NiIsInR5cCI6Ik如果你細(xì)致得去看的話會發(fā)現(xiàn)其實這是一個分為 3 段的字符串，段與段之間用 “.”【點號】 隔開，在 JWT 的概念中，每一段的名稱分別為：
Header.Payload.Signature在字符串中每一段都是被 base64url 編碼后的 JSON，其中 Payload 段可能被加密。
JWT 的 Header 通常包含兩個字段，分別是：typ(type) 和 alg(algorithm)。
一個簡單的例子：
{
"alg": "HS256",
"typ": "JWT"
}我們對他進(jìn)行編碼后是：
>>> base64.b64encode(json.dumps({"alg":"HS256","typ":"JWT"}))
'eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9'JWT 中的 Payload 其實就是真實存儲我們需要傳遞的信息的部分，例如正常我們會存儲些用戶 ID、用戶名之類的。此外，還包含一些例如發(fā)布人、過期日期等的元數(shù)據(jù)。
但是，這部分和 Header 部分不一樣的地方在于這個地方可以加密，而不是簡單得直接進(jìn)行 BASE64 編碼。但是這里我為了解釋方便就直接使用 BASE64 編碼，需要注意的是，這里的 BASE64 編碼稍微有點不一樣，切確得說應(yīng)該是 Base64UrlEncoder，和 Base64 編碼的區(qū)別在于會忽略最后的 padding（=號），然后 '-' 會被替換成'_'。
舉個例子，例如我們的 Payload 是：
{"user_id":"zhangsan"}那么直接 Base64 的話應(yīng)該是：
>>> base64.urlsafe_b64encode('{"user_id":"zhangsan"}')
'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ=='然后去掉=號，最后應(yīng)該是：
'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ'Signature 部分其實就是對我們前面的 Header 和 Payload 部分進(jìn)行簽名，保證 Token 在傳輸?shù)倪^程中沒有被篡改或者損壞，簽名的算法也很簡單，但是，為了加密，所以除了 Header 和 Payload 之外，還多了一個密鑰字段，完整算法為：
Signature=HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)還是以前面的例子為例，
base64UrlEncode(header)=》 eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9
base64UrlEncode(payload)=》 eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQsecret 就設(shè)為："secret", 那最后出來的簽名應(yīng)該是：
>>> import hmac
>>> import hashlib
>>> import base64
>>> dig=hmac.new('secret', >>> msg="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ",
digestmod=>>> base64.b64encode(dig.digest())
'ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs='
將上面三個部分組裝起來就組成了我們的 JWT token了，所以我們的
{'user_id': 'zhangsan'}的 token 就是：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ.ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs1.首先，前端通過Web表單將自己的用戶名和密碼發(fā)送到后端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協(xié)議），從而避免敏感信息被嗅探。
2.后端核對用戶名和密碼成功后，將用戶的id等其他信息作為JWT Payload（負(fù)載），將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字符串。
3.后端將JWT字符串作為登錄成功的返回結(jié)果返回給前端。前端可以將返回的結(jié)果保存在localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。
4.前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
5.后端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
6.驗證通過后后端使用JWT中包含的用戶信息進(jìn)行其他邏輯操作，返回相應(yīng)結(jié)果。
隨著應(yīng)用程序的擴(kuò)大和用戶數(shù)量的增加，你必將開始水平或垂直擴(kuò)展。
session數(shù)據(jù)通過文件或數(shù)據(jù)庫存儲在服務(wù)器的內(nèi)存中。在水平擴(kuò)展方案中，你必須開始復(fù)制服務(wù)器數(shù)據(jù)，你必須創(chuàng)建一個獨立的中央session存儲系統(tǒng)，以便所有應(yīng)用程序服務(wù)器都可以訪問。否則，由于session存儲的缺陷，你將無法擴(kuò)展應(yīng)用程序。
解決這個挑戰(zhàn)的另一種方法是使用 sticky session。
你還可以將session存儲在磁盤上，使你的應(yīng)用程序在云環(huán)境中輕松擴(kuò)展。這類解決方法在現(xiàn)代大型應(yīng)用中并沒有真正發(fā)揮作用。
建立和維護(hù)這種分布式系統(tǒng)涉及到深層次的技術(shù)知識，并隨之產(chǎn)生更高的財務(wù)成本。在這種情況下，使用JWT是無縫的;由于基于token的身份驗證是無狀態(tài)的，所以不需要在session中存儲用戶信息。
我們的應(yīng)用程序可以輕松擴(kuò)展，因為我們可以使用token從不同的服務(wù)器訪問資源，而不用擔(dān)心用戶是否真的登錄到某臺服務(wù)器上。你也可以節(jié)省成本，因為你不需要專門的服務(wù)器來存儲session。為什么？因為沒有session！
注意：如果你正在構(gòu)建一個小型應(yīng)用程序，這個程序完全不需要在多臺服務(wù)器上擴(kuò)展，并且不需要RESTful API的，那么session機(jī)制是很棒的。 如果你使用專用服務(wù)器運(yùn)行像Redis那樣的工具來存儲session，那么session也可能會為你完美地運(yùn)作！
JWT簽名旨在防止在客戶端被篡改，但也可以對其進(jìn)行加密，以確保token攜帶的claim 非常安全。JWT主要是直接存儲在web存儲（本地/session存儲）或cookies中。 JavaScript可以訪問同一個域上的Web存儲。這意味著你的JWT可能容易受到XSS（跨站腳本）攻擊。惡意JavaScript嵌入在頁面上，以讀取和破壞Web存儲的內(nèi)容。事實上，很多人主張，由于XSS攻擊，一些非常敏感的數(shù)據(jù)不應(yīng)該存放在Web存儲中。一個非常典型的例子是確保你的JWT不將過于敏感/可信的數(shù)據(jù)進(jìn)行編碼，例如用戶的社會安全號碼。
最初，我提到JWT可以存儲在cookie中。事實上，JWT在許多情況下被存儲為cookie，并且cookies很容易受到CSRF（跨站請求偽造）攻擊。預(yù)防CSRF攻擊的許多方法之一是確保你的cookie只能由你的域訪問。作為開發(fā)人員，不管是否使用JWT，確保必要的CSRF保護(hù)措施到位以避免這些攻擊。
現(xiàn)在，JWT和session ID也會暴露于未經(jīng)防范的重放攻擊。建立適合系統(tǒng)的重放防范技術(shù)，完全取決于開發(fā)者。解決這個問題的一個方法是確保JWT具有短期過期時間。雖然這種技術(shù)并不能完全解決問題。然而，解決這個挑戰(zhàn)的其他替代方案是將JWT發(fā)布到特定的IP地址并使用瀏覽器指紋。
注意：使用HTTPS / SSL確保你的Cookie和JWT在客戶端和服務(wù)器傳輸期間默認(rèn)加密。這有助于避免中間人攻擊！
現(xiàn)代應(yīng)用程序的常見模式是從RESTful API查詢使用JSON數(shù)據(jù)。目前大多數(shù)應(yīng)用程序都有RESTful API供其他開發(fā)人員或應(yīng)用程序使用。由API提供的數(shù)據(jù)具有幾個明顯的優(yōu)點，其中之一就是這些數(shù)據(jù)可以被多個應(yīng)用程序使用。在這種情況下，傳統(tǒng)的使用session和Cookie的方法在用戶認(rèn)證方面效果不佳，因為它們將狀態(tài)引入到應(yīng)用程序中。
RESTful API的原則之一是它應(yīng)該是無狀態(tài)的，這意味著當(dāng)發(fā)出請求時，總會返回帶有參數(shù)的響應(yīng)，不會產(chǎn)生附加影響。用戶的認(rèn)證狀態(tài)引入這種附加影響，這破壞了這一原則。保持API無狀態(tài)，不產(chǎn)生附加影響，意味著維護(hù)和調(diào)試變得更加容易。
另一個挑戰(zhàn)是，由一個服務(wù)器提供API，而實際應(yīng)用程序從另一個服務(wù)器調(diào)用它的模式是很常見的。為了實現(xiàn)這一點，我們需要啟用跨域資源共享（CORS）。Cookie只能用于其發(fā)起的域，相對于應(yīng)用程序，對不同域的API來說，幫助不大。在這種情況下使用JWT進(jìn)行身份驗證可以確保RESTful API是無狀態(tài)的，你也不用擔(dān)心API或應(yīng)用程序由誰提供服務(wù)。
對此的批判性分析是非常必要的。當(dāng)從客戶端向服務(wù)器發(fā)出請求時，如果大量數(shù)據(jù)在JWT內(nèi)進(jìn)行編碼，則每個HTTP請求都會產(chǎn)生大量的開銷。然而，在會話中，只有少量的開銷，因為SESSION ID實際上非常小。看下面這個例子：
JWT有5個claim：
{
"sub": "1234567890",
"name": "Prosper Otemuyiwa",
"admin": true,
"role": "manager",
"company": "Auth0"
}
編碼時，JWT的大小將是SESSION ID（標(biāo)識符）的幾倍，從而在每個HTTP請求中，JWT比SESSION ID增加更多的開銷。而對于session，每個請求在服務(wù)器上需要查找和反序列化session。
JWT通過將數(shù)據(jù)保留在客戶端的方式以空間換時間。你應(yīng)用程序的數(shù)據(jù)模型是一個重要的影響因素，因為通過防止對服務(wù)器數(shù)據(jù)庫不間斷的調(diào)用和查詢來減少延遲。需要注意的是不要在JWT中存儲太多的claim，以避免發(fā)生巨大的，過度膨脹的請求。
值得一提的是，token可能需要訪問后端的數(shù)據(jù)庫。特別是刷新token的情況。他們可能需要訪問授權(quán)服務(wù)器上的數(shù)據(jù)庫以進(jìn)行黑名單處理。獲取有關(guān)刷新token和何時使用它們的更多信息。
現(xiàn)代web應(yīng)用程序的另一種常見模式是，它們通常依賴于下游服務(wù)。例如，在原始請求被解析之前，對主應(yīng)用服務(wù)器的調(diào)用可能會向下游服務(wù)器發(fā)出請求。這里的問題是，cookie不能很方便地流到下游服務(wù)器，也不能告訴這些服務(wù)器關(guān)于用戶的身份驗證狀態(tài)。由于每個服務(wù)器都有自己的cookie方案，所以阻力很大，并且連接它們也是困難的。JSON Web Token再次輕而易舉地做到了！
此外，無狀態(tài)JWT的實效性相比session太差，只有等到過期才可銷毀，而session則可手動銷毀。
例如有個這種場景，如果JWT中存儲有權(quán)限相關(guān)信息，比如當(dāng)前角色為 admin，但是由于JWT所有者濫用自身權(quán)利，高級管理員將權(quán)利濫用者的角色降為 user。但是由于 JWT 無法實時刷新，必需要等到 JWT 過期，強(qiáng)制重新登錄時，高級管理員的設(shè)置才能生效。
或者是用戶發(fā)現(xiàn)賬號被異地登錄，然后修改密碼，此時token還未過期，異地的賬號一樣可以進(jìn)行操作包括修改密碼。
但這種場景也不是沒有辦法解決，解決辦法就是將JWT生成的token存入到redis或者數(shù)據(jù)庫中，當(dāng)用戶登出或作出其他想要讓token失效的舉動，可通過刪除token在數(shù)據(jù)庫或者redis里面的對應(yīng)關(guān)系來解決這個問題。
我這個項目中使用的是JWT，使用方法如下：
首先安裝JWT庫：
npm install jsonwebtoken然后創(chuàng)建簽名數(shù)據(jù)，生成token：
復(fù)制代碼let jwt=require('jsonwebtoken');
var token=jwt.sign({ name: '張三' }, 'shhhhh');
console.log(token);運(yùn)行程序可以看到打印出來的內(nèi)容類似這樣：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoi5byg5LiJIiwiaWF0IjoxNDYyODgxNDM3fQ.uVWC2h0_r1F4FZ3qDLkGN5KoFYbyZrFpRJMONZrJJog之后，對token字符串，可以這樣解碼：
let decoded=jwt.decode(token);
console.log(decoded);將打印出：
{ name: '張三', iat: 1462881437 }其中iat是時間戳，即簽名時的時間（注意：單位是秒）。
不過，一般我們不會使用decode方法，因為它只是簡單的對claims部分的做base64解碼。
我們需要的是驗證claims的內(nèi)容是否被篡改。
此時我們需要使用verify方法：
let decoded=jwt.verify(token, 'shhhhh');
console.log(decoded);雖然打印出的內(nèi)容和decode方法是一樣的。但是是經(jīng)過校驗的。
我們可以改變校驗用的密鑰，比如改為shzzzz，使之和加密時的密鑰不一致。那么解碼就會出現(xiàn)報錯：
JsonWebTokenError: invalid signature我們也可以偷偷修改token的claims或者h(yuǎn)eader部分，會得到這樣的報錯：
JsonWebTokenError: invalid token最后，根據(jù)自己的需求，決定是否需要將生成的token存入數(shù)據(jù)庫或者redis，但建議不要存儲用戶密碼等敏感信息。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
