jsonwebtoken
JSONWebToken(JWT)是一個敞開規(guī)范(RFC7519)，它界說了一種緊湊且自包括的方法，運(yùn)用JSON對象在各方之間安全地傳輸信息。此信息能夠驗(yàn)證和信賴，由于它是數(shù)字簽名的。JWT能夠運(yùn)用密鑰（運(yùn)用HMAC算法）或運(yùn)用RSA或ECDSA的公鑰/私鑰對進(jìn)行簽名。
雖然JWT能夠加密以在各方之間供給保密性，但我們將專注于簽名令牌。已經(jīng)簽名的token能夠驗(yàn)證其間包括的聲明（claims）的完整性，而加密的令牌會向其他方躲藏這些聲明。當(dāng)運(yùn)用公鑰/私鑰對對令牌進(jìn)行簽名時，簽名還能證明只有持有私鑰的一方才是簽署它的一方。
jsonwebtoken安裝使用教程
JSONWebToken（縮寫JWT）是目前最盛行的跨域認(rèn)證解決計(jì)劃，本文介紹它的原理和用法。
一、跨域認(rèn)證問題
互聯(lián)網(wǎng)服務(wù)離不開用戶認(rèn)證。一般流程是下面這樣。
用戶向服務(wù)器發(fā)送用戶名和暗碼
服務(wù)器驗(yàn)證通往后，在當(dāng)前對話（session）中保留相關(guān)數(shù)據(jù)，如用戶人物、登陸時刻等
服務(wù)器向用戶回來一個session_id，寫入用戶的Cookie
用戶隨后的每一次懇求，都會通過Cookie，將session_id傳回服務(wù)器
服務(wù)器收到session_id，找到前期保存的數(shù)據(jù)，由此得知用戶身份
這種形式的問題在于，擴(kuò)展性（scaling）不好。單機(jī)當(dāng)然沒有問題，如果是服務(wù)器集群，或許是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求session數(shù)據(jù)共享，每臺服務(wù)器都能夠讀取session。
舉例來說，A網(wǎng)站和B網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)。現(xiàn)在要求，用戶只需在其中一個網(wǎng)站登錄，再拜訪另一個網(wǎng)站就會主動登錄，請問怎樣完成？
一種計(jì)劃是session數(shù)據(jù)耐久化，寫入數(shù)據(jù)庫或其他耐久層。各種服務(wù)收到懇求后，都向耐久層懇求數(shù)據(jù)。這種計(jì)劃的長處是架構(gòu)清晰，缺陷是工程量比較大。別的，耐久層如果掛了，就會單點(diǎn)失利。
另一種計(jì)劃是服務(wù)器索性不保存session數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端，每次懇求都發(fā)回服務(wù)器。JWT便是這種計(jì)劃的一個代表。
二、JWT的原理
JWT的原理是，服務(wù)器認(rèn)證今后，生成一個JSON目標(biāo)，發(fā)回給用戶，就像下面這樣。
{“姓名”:”張三”,”人物”:”管理員”,”到期時刻”:”2022年02月22日22點(diǎn)22分”}
今后，用戶與服務(wù)端通信的時分，都要發(fā)回這個JSON目標(biāo)。服務(wù)器徹底只靠這個目標(biāo)確定用戶身份。為了避免用戶篡改數(shù)據(jù)，服務(wù)器在生成這個目標(biāo)的時分，會加上簽名（詳見后文）。
服務(wù)器就不保存任何session數(shù)據(jù)了，也便是說，服務(wù)器變成無狀態(tài)了，從而比較簡單完成擴(kuò)展。
三、JWT的數(shù)據(jù)結(jié)構(gòu)
實(shí)際的JWT大約就像下面這樣。
它是一個很長的字符串，中間用點(diǎn)（.）分隔成三個部分。留意，JWT內(nèi)部是沒有換行的，這里僅僅為了便于展現(xiàn)，將它寫成了幾行。
JWT的三個部分順次如下。
header（頭部）
payload（負(fù)載）
signature（簽名）
寫成一行，便是下面的姿態(tài)。
header.payload.signature
下面順次介紹這三個部分。
3.1Header
Header部分是一個JSON目標(biāo)，描繪JWT的元數(shù)據(jù)，通常是下面的姿態(tài)。
{“alg”:”HS256″,”typ”:”JWT”}
上邊代碼中，alg特色表明簽名的算法（algorithm），默認(rèn)是HMACSHA256（寫成HS256）；typ特色表明這個令牌（token）的類型（type），JWT令牌統(tǒng)一寫為JWT。
最后，將上邊的JSON目標(biāo)運(yùn)用Base64URL算法（詳見后文）轉(zhuǎn)成字符串。
3.2Payload
Payload部分也是一個JSON目標(biāo)，用來寄存實(shí)際需求傳遞的數(shù)據(jù)。JWT規(guī)則了7個官方字段，供選用。
iss(issuer)：簽發(fā)人
exp(expirationtime)：過期時刻
sub(subject)：主題
aud(audience)：受眾
nbf(NotBefore)：收效時刻
iat(IssuedAt)：簽發(fā)時刻
jti(JWTID)：編號
除了官方字段，你還能夠在這個部分定義私有字段，下面便是一個例子。
{“sub”:”1234567890″,”name”:”JohnDoe”,”admin”:true}
留意，JWT默認(rèn)是不加密的，任何人都能夠讀到，所以不要把秘密信息放在這個部分。
這個JSON目標(biāo)也要運(yùn)用Base64URL算法轉(zhuǎn)成字符串。
3.3Signature
Signature部分是對前兩部分的簽名，避免數(shù)據(jù)篡改。
首先，需求指定一個密鑰（secret）。這個密鑰只有服務(wù)器才知道，不能走漏給用戶。然后，運(yùn)用Header里邊指定的簽名算法（默認(rèn)是HMACSHA256），依照下面的公式產(chǎn)生簽名。
HMACSHA256(
base64UrlEncode(header)+”.”+
base64UrlEncode(payload),
secret)
算出簽名今后，把Header、Payload、Signature三個部分拼成一個字符串，每個部分之間用”點(diǎn)”（.）分隔，就能夠回來給用戶。
3.4Base64URL
前面說到，Header和Payload串型化的算法是Base64URL。這個算法跟Base64算法根本相似，但有一些小的不同。
JWT作為一個令牌（token），有些場合可能會放到URL（比方api.example.com/?token=xxx）。Base64有三個字符+、/和=，在URL里邊有特別含義，所以要被替換掉：=被省略、+替換成-，/替換成_。這便是Base64URL算法。
四、JWT的運(yùn)用方法
客戶端收到服務(wù)器回來的JWT，能夠儲存在Cookie里邊，也能夠儲存在localStorage。
此后，客戶端每次與服務(wù)器通信，都要帶上這個JWT。你能夠把它放在Cookie里邊主動發(fā)送，但是這樣不能跨域，所以更好的做法是放在HTTP懇求的頭信息Authorization字段里邊。
Authorization:Bearer<token>
另一種做法是，跨域的時分，JWT就放在POST懇求的數(shù)據(jù)體里邊。
五、JWT的幾個特色
（1）JWT默認(rèn)是不加密，但也是能夠加密的。生成原始Token今后，能夠用密鑰再加密一次。
（2）JWT不加密的情況下，不能將秘密數(shù)據(jù)寫入JWT。
（3）JWT不僅能夠用于認(rèn)證，也能夠用于交流信息。有用運(yùn)用JWT，能夠降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。
（4）JWT的最大缺陷是，由于服務(wù)器不保存session狀態(tài)，因此無法在運(yùn)用過程中廢止某個token，或許更改token的權(quán)限。也便是說，一旦JWT簽發(fā)了，在到期之前就會始終有用，除非服務(wù)器布置額定的邏輯。
（5）JWT本身包含了認(rèn)證信息，一旦走漏，任何人都能夠獲得該令牌的所有權(quán)限。為了減少盜用，JWT的有用期應(yīng)該設(shè)置得比較短。關(guān)于一些比較重要的權(quán)限，運(yùn)用時應(yīng)該再次對用戶進(jìn)行認(rèn)證。
（6）為了減少盜用，JWT不應(yīng)該運(yùn)用HTTP協(xié)議明碼傳輸，要運(yùn)用HTTPS協(xié)議傳輸。
