1.JWT是什么？

詳細的解釋是：Json web token (JWT)是為了在網(wǎng)絡應用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標準（(RFC 7519)。該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便于從資源服務器獲取資源，也可以增加一些額外的其它業(yè)務邏輯所必須的聲明信息，該token也可直接被用于認證，也可被加密。

簡單理解的話： JWT是一個開放標準，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息，且該信息可以被驗證和信任，因為它是數(shù)字簽名的。

是不是還有點迷糊？那就請接著往下看。

2.起源：

說到JWT，就需要先來聊一下傳統(tǒng)的session認證和基于token的認證的區(qū)別。

2.1傳統(tǒng)的session認證

我們知道，http協(xié)議本身是一種無狀態(tài)的協(xié)議，而這就意味著如果用戶向我們的應提用供了用戶名和密碼來進行用戶認證，那么下一次請求時，用戶還要再一次進行用戶認證才行，因為根據(jù)http協(xié)議，我們并不能知道是哪個用戶發(fā)出的請求，所以為了讓我們的應用能識別是哪個用戶發(fā)出的請求，我們只能在服務器存儲一份用戶登錄的信息，這份登錄信息會在響應時傳遞給瀏覽器，告訴其保存為cookie,以便下次請求時發(fā)送給我們的應用，這樣我們的應用就能識別請求來自哪個用戶了,這就是傳統(tǒng)的基于session認證。

但是這種基于session的認證使應用本身很難得到擴展，隨著不同客戶端用戶的增加，獨立的服務器已無法承載更多的用戶，而這時候基于session認證應用的問題就會暴露出來：

Session: 每個用戶經(jīng)過我們的應用認證之后，我們的應用都要在服務端做一次記錄，以方便用戶下次請求的鑒別，通常而言session都是保存在內存中，而隨著認證用戶的增多，服務端的開銷會明顯增大。

擴展性: 用戶認證之后，服務端做認證記錄，如果認證的記錄被保存在內存中的話，這意味著用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源，這樣在分布式的應用上，相應的限制了負載均衡器的能力，這也意味著限制了應用的擴展能力。

CSRF: 因為是基于cookie來進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊。

2.2基于token的鑒權機制

基于token的鑒權機制類似于http協(xié)議也是無狀態(tài)的，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味著基于token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了，這就為應用的擴展提供了便利。

流程上是這樣的：

用戶使用用戶名密碼來請求服務器

服務器進行驗證用戶的信息

服務器通過驗證發(fā)送給用戶一個token

客戶端存儲token，并在每次請求時附送上這個token值

服務端驗證token值，并返回數(shù)據(jù)

這個token必須要在每次請求時傳遞給服務端，它應該保存在請求頭里， 另外，服務端要支持CORS(跨來源資源共享)策略，一般我們在服務端這么做就可以了Access-Control-Allow-Origin: *。

那么我們現(xiàn)在回到JWT的主題上。

3. JSON Web Token的結構是什么樣的

第一部分為頭部（header)，第二部分為載荷（payload,，類似于飛機上承載的物品)，第三部分是簽證（signature)。每部分中間使用點（.）分隔，比如：xxxxx.yyyyy.zzzzz。

3.1header

jwt的頭部承載兩部分信息：

• 聲明類型，這里是jwt
• 聲明加密的算法 通常直接使用 HMAC SHA256

完整的頭部就像下面這樣的JSON：

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

然后將頭部進行base64加密（該加密是可以對稱解密的),構成了第一部分。

3.2playload

載荷就是存放有效信息的地方。這個名字像是特指飛機上承載的貨品，這些有效信息包含三個部分

• 標準中注冊的聲明
• 公共的聲明
• 私有的聲明

標準中注冊的聲明 (建議但不強制使用) ：

• iss: jwt簽發(fā)者
• sub: jwt所面向的用戶
• aud: 接收jwt的一方
• exp: jwt的過期時間，這個過期時間必須要大于簽發(fā)時間
• nbf: 定義在什么時間之前，該jwt都是不可用的.
• iat: jwt的簽發(fā)時間
• jti: jwt的唯一身份標識，主要用來作為一次性token,從而回避重放攻擊。

公共的聲明 ：

公共的聲明可以添加任何的信息，一般添加用戶的相關信息或其他業(yè)務需要的必要信息，但不建議添加敏感信息，因為該部分在客戶端可解密。

私有的聲明 ：

私有聲明是提供者和消費者所共同定義的聲明，一般不建議存放敏感信息，因為base64是對稱解密的，意味著該部分信息可以歸類為明文信息。

定義一個payload:

{"sub": "1234567890","name": "zhangsan","admin": true }

然后將其進行base64加密，得到Jwt的第二部分。

3.3signature

jwt的第三部分是一個簽證信息，這個簽證信息由三部分組成，防止內容被處篡改：

• header (base64后的)
• payload (base64后的)
• secret

這個部分需要base64加密后的header和base64加密后的payload使用.連接組成的字符串，然后通過header中聲明的加密方式進行加鹽secret組合加密，然后就構成了jwt的第三部分。

var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);var signature = HMACSHA256(encodedString, 'secret');

將這三部分用，連接成一個完整的字符串，構成了最終的jwt:

注意：secret是保存在服務器端的，jwt的簽發(fā)生成也是在服務器端的，secret就是用來進行jwt的簽發(fā)和jwt的驗證，所以，它就是你服務端的私鑰，在任何場景都不應該流露出去。一旦客戶端得知這個secret, 那就意味著客戶端是可以自我簽發(fā)jwt了。

如何應用

一般是在請求頭里加入Authorization，并加上Bearer標注：

fetch('api/user/1', {
? headers: {
??? 'Authorization': 'Bearer ' + token
? }
})

服務端會驗證token，如果驗證通過就會返回相應的資源。整個流程就是這樣的:

4.總結

4.1優(yōu)點

• 因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
• 因為有了payload部分，所以JWT可以在自身存儲一些其他業(yè)務邏輯所必要的非敏感信息。
• 便于傳輸，jwt的構成非常簡單，字節(jié)占用很小，所以它是非常便于傳輸?shù)摹?/li>
• 它不需要在服務端保存會話信息, 所以它易于應用的擴展

4.2安全相關

• 不應該在jwt的payload部分存放敏感信息，因為該部分是客戶端可解密的部分。
• 保護好secret私鑰，該私鑰非常重要。
• 如果可以，請使用https協(xié)議

總結

以上是生活随笔為你收集整理的GD项目回顾之JWT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。