什么是JWT-有解無憂

JSON Web Token（縮寫 JWT）是目前最流行的跨域認證解決方案，

傳統的session認證

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

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

基于session認證所顯露的問題

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

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

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

最全面的Java面試網站

基于token的鑒權機制

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

流程上是這樣的：

用戶使用用戶名密碼來請求服務器
服務器進行驗證用戶的資訊
服務器通過驗證發送給用戶一個token
客戶端存盤token，并在每次請求時附送上這個token值
服務端驗證token值，并回傳資料

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

JWT長什么樣？

JWT是由三段資訊構成的，將這三段資訊文本用.鏈接一起就構成了Jwt字串，就像這樣:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW

JWT的構成

第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload, 類似于飛機上承載的物品)，第三部分是簽證（signature).

jwt的頭部承載兩部分資訊：

宣告型別，這里是jwt
宣告加密的演算法通常直接使用 HMAC SHA256

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

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

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

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

標準中注冊的宣告
公共的宣告
私有的宣告

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

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

公共的宣告 ：
公共的宣告可以添加任何的資訊，一般添加用戶的相關資訊或其他業務需要的必要資訊.但不建議添加敏感資訊，因為該部分在客戶端可解密.

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

定義一個payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

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

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

最全面的Java面試網站

signature

jwt的第三部分是一個簽證資訊，這個簽證資訊由三部分組成：

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

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

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

如何應用

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

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

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

總結

優點

因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用，
因為有了payload部分，所以JWT可以在自身存盤一些其他業務邏輯所必要的非敏感資訊，
便于傳輸，jwt的構成非常簡單，位元組占用很小，所以它是非常便于傳輸的，
它不需要在服務端保存會話資訊, 所以它易于應用的擴展

安全相關

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

最后給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/548567.html

標籤：Java

上一篇：day02-功能實作02

下一篇：SSM框架筆記慶祝學習SSM框架結束！！！