?2016-2026 Matools All rights reserved,
粵ICP備17059708號
前言：
? 現(xiàn)在越來越多的項目或多或少會用到JWT，為什么會出現(xiàn)使用JWT這樣的場景的呢？
?
假設(shè)現(xiàn)在有一個APP，后臺是分布式系統(tǒng)。APP的首頁模塊部署在上海機房的服務(wù)器上，子頁面模塊部署在深圳機房的服務(wù)器上。此時你從首頁登錄了該APP，然后跳轉(zhuǎn)到子頁面模塊。session在兩個機房之間不能同步，用戶是否需要重新登錄？
傳統(tǒng)的方式（cookie+session）需要重新登錄，用戶體驗不好。session共享（在多臺物理機之間傳輸和復制session）方式對網(wǎng)絡(luò)IO的壓力大，延遲太長，用戶體驗也不好。
?
說到這大家可能會想到，用服務(wù)器的session_id存儲到cookies中也能做到，為什么非要用token呢？網(wǎng)上有許多文章來比較token和session的優(yōu)缺點，其實，開發(fā)web應(yīng)用的話用哪種都行。但如果是開發(fā)api接口，前后端分離，最好使用token，為什么這么說呢，因為session+cookies是基于web的。但是針對?api接口，可能會考慮到移動端，app是沒有cookies和session的。
? Session方式存儲用戶信息的最大問題在于要占用大量服務(wù)器內(nèi)存，增加服務(wù)器的開銷。
? 而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力。Session的狀態(tài)是存儲在服務(wù)器端，客戶端只有session
id；而Token的狀態(tài)是存儲在客戶端
原理：
JSON Web Token（縮寫 JWT）
? ? JWT 的原理是，服務(wù)器認證以后，生成一個 JSON 對象，發(fā)回給用戶，以后，用戶與服務(wù)端通信的時候，都要發(fā)回這個 JSON 對象。
? 服務(wù)器完全只靠這個對象認定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個對象的時候，會加上簽名。
? 服務(wù)器就不保存任何 session 數(shù)據(jù)了，也就是說，服務(wù)器變成無狀態(tài)了，從而比較容易實現(xiàn)擴展。
組合：
?JWT 的三個部分依次是：Header（頭部）、Payload（負載）、Signature（簽名）
寫成一行，就是下面的樣子。
Header.Payload.Signature
?一、Header
header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）
{ "alg": "HS256", //alg屬性表示簽名的算法（algorithm），默認是 HMAC SHA256（寫成 HS256） "typ": "
JWT" //typ屬性表示這個令牌（token）的類型（type） }
然后用Base64對這個JSON編碼就得到JWT的第一部分
二、Payload
JWT的第二部分是payload，它包含聲明（要求）。聲明是關(guān)于實體(通常是用戶)和其他數(shù)據(jù)的聲明
JWT 規(guī)定了7個官方字段
* iss (issuer)：簽發(fā)人
* exp (expiration time)：過期時間
* sub (subject)：主題
* aud (audience)：受眾
* nbf (Not Before)：生效時間
* iat (Issued At)：簽發(fā)時間
* jti (JWT ID)：編號
除了官方字段，你還可以在這個部分定義私有字段，下面就是一個例子
{ "sub": "1234567890", "name": "John Doe", "admin": true }
注意，不要在JWT的payload或header中放置敏感信息，除非它們是加密的
三、Signature
Signature
部分是對前兩部分的簽名，防止數(shù)據(jù)篡改。簽名是用于驗證消息在傳遞過程中有沒有被更改，并且，對于使用私鑰簽名的token，它還可以驗證JWT的發(fā)送方是否為它所稱的發(fā)送方。
為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個秘鑰，簽名算法是header中指定的那個，然對它們簽名即可。按照下面的公式產(chǎn)生簽名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，就可以返回給用戶。
?
開始：
?一、客戶端收到服務(wù)器返回的 JWT，可以儲存在 Cookie 里面，也可以儲存在 localStorage。
此后，客戶端每次與服務(wù)器通信，都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發(fā)送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息
Authorization字段里面。
Authorization: Bearer <token>
二、JWT 就放在 POST 請求的數(shù)據(jù)體里面，那么跨源資源共享(CORS)將不會成為問題，因為它不使用cookie
1.應(yīng)用（或者客戶端）想授權(quán)服務(wù)器請求授權(quán)。例如，如果用授權(quán)碼流程的話，就是/oauth/authorize
2.當授權(quán)被許可以后，授權(quán)服務(wù)器返回一個access token給應(yīng)用
3.應(yīng)用使用access token訪問受保護的資源（比如：API）
特點：
1.JWT 默認是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。
2.JWT 不加密的情況下，不能將秘密數(shù)據(jù)寫入 JWT。
3.JWT 的最大缺點是，由于服務(wù)器不保存 session 狀態(tài)，因此無法在使用過程中廢止某個 token，或者更改 token 的權(quán)限。也就是說，一旦
JWT 簽發(fā)了，在到期之前就會始終有效，除非服務(wù)器部署額外的邏輯。
4.JWT 本身包含了認證信息，一旦泄露，任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用，JWT
的有效期應(yīng)該設(shè)置得比較短。對于一些比較重要的權(quán)限，使用時應(yīng)該再次對用戶進行認證。
注意：
JWT 是 JSON 格式的被加密了的字符串
JWT 的核心是密鑰，就是 JSON 數(shù)據(jù)。這是你關(guān)心的，并希望安全傳遞出去的數(shù)據(jù)。JWT 如何做到這一點，并使你信任它，就是加密簽名。
?
被篡改之后
?
?
總結(jié)：
參考官方文檔：JSON Web Tokens <https://jwt.io/>
?
熱門工具 換一換