什麼是JWT Json web token (JWT), 是為了在網路應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用於分散式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息， ...
什麼是JWT
Json web token (JWT), 是為了在網路應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用於分散式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源伺服器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
起源
說起JWT，我們應該來談一談基於token的認證和傳統的session認證的區別。
基於token的鑒權機制
基於token的鑒權機制類似於http協議也是無狀態的，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味著基於token認證機制的應用不需要去考慮用戶在哪一臺伺服器登錄了，這就為應用的擴展提供了便利。
流程上是這樣的：
- 用戶使用用戶名密碼來請求伺服器
- 伺服器進行驗證用戶的信息
- 伺服器通過驗證發送給用戶一個token
- 客戶端存儲token，併在每次請求時附送上這個token值
- 服務端驗證token值，並返回數據
這個token必須要在每次請求時傳遞給服務端，它應該保存在請求頭裡， 另外，服務端要支持CORS(跨來源資源共用)策略，一般我們在服務端這麼做就可以了Access-Control-Allow-Origin: *。
那麼我們現在回到JWT的主題上。
JWT長什麼樣？
JWT是由三段信息構成的，將這三段信息文本用.鏈接一起就構成了Jwt字元串。就像這樣:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
JWT的構成
第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload, 類似於飛機上承載的物品)，第三部分是簽證（signature).
header
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
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，如果驗證通過就會返回相應的資源。整個流程就是這樣的:
jwt-diagram
總結
優點
- 因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
- 因為有了payload部分，所以JWT可以在自身存儲一些其他業務邏輯所必要的非敏感信息。
- 便於傳輸，jwt的構成非常簡單，位元組占用很小，所以它是非常便於傳輸的。
- 它不需要在服務端保存會話信息, 所以它易於應用的擴展
缺點：也是自解析，伺服器端無法對token管理、註銷、刷新、有效期延長。舉個例子，我發現賬號可能被盜了，於是去修改密碼，但是修改了密碼後原jwt還是能夠暢通無阻。為瞭解決這個問題，伺服器端依然會持久化token，一旦持久化token，那麼就沒必要用jwt了，jwt第三段和他的加密證書那套就顯得多餘。
安全相關
- 不應該在jwt的payload部分存放敏感信息，因為該部分是客戶端可解密的部分。
- 保護好secret私鑰，該私鑰非常重要。
- 如果可以，請使用https協議
作者還在學習中，發現錯誤的請在評論區留言。 如果有客友覺得文章還行的話，請點波推薦哦
