當下，JWT（JSON Web Token）令牌認證已經變得越來越流行。本文主要介紹JWT令牌認證與傳統的Session會話認證機制的區別。
為什么需要認證？
HTTP是一種無狀態協議，那就意味着當前的客戶端的請求與任何之前的請求是獨立不依賴的，而服務器也並不會記錄任何請求信息。例如，如果你只是簡單地訪問靜態頁面（例如訪問 www.yiidian.com ），服務器實際上不需要知道客戶端是誰，而只會給客戶端返回純粹的頁面內容。另一方面，如果你想在Facebook上進行資料上的更改，則必須向一點教程網服務器證明你是該帳戶的擁有者。簡而言之，您需要先驗證自己的身份，然后服務器才能為你提供訪問敏感信息的權限。在了解JWT認證之前，我們先來看看傳統的Session會話認證吧。
Session會話認證
在Session會話認證模型中，在用戶登錄並授權后，服務器將創建客戶端唯一的Session。服務器將Session ID返回給客戶端，然后客戶端將其存儲在瀏覽器的cookie中。在隨后的HTTP調用中，cookie將自動包含在HTTP請求頭中，服務器將通過cookie中記錄的Session ID得知客戶端的身份。盡管cookie存儲在客戶端，但是由於驗證是在服務器上完成的，因此該認證模型屬於服務器端會話。
說到這里，您可能會想：HTTP協議不是無狀態的么？那服務器如何記住客戶端的身份？
服務器端會話：實際上不是無狀態的
從技術上講，HTTP無狀態協議不會禁止服務器存儲信息。大多數Web應用程序都需要存儲某種形式的狀態，以便知道客戶端的Session ID是否有效。例如，服務器可能會把Session ID存儲在服務器內存，這樣，只要先前經過身份驗證的客戶端再次發出請求，服務器就可以簡單地在內存查找Session ID，並驗證客戶端是否已經通過了身份驗證。
Session認證的優點
- Session ID有過期時間
- Session ID可以被撤銷/刪除
- Cookie的數據量少，存儲Session ID非常輕便
Session認證的缺點
- 分布式/跨服務器架構 中的Session ID共享問題
在分布式架構中，客戶端在其中一台服務器驗證通過后，Session ID只會存儲在當前服務器中，當客戶端訪問其他服務器時，並不能查找到之前的Session ID，這樣就無法正常驗證了。為了確保所有服務器具有相同Session ID，其中一種方法是讓所有服務器使用共享的Redis緩存（如上圖所示）。
JWT令牌認證
在JWT（JSON Web Token）認證模型中，服務器不會在用戶登錄后返回Session ID，而是將簽名（加密）的Token字符串返回給客戶端。此簽名的Token本質上是一個JSON對象，其中包含服務器使用私鑰或公鑰/私鑰簽名的身份驗證信息。
在后續的HTTP請求中，客戶端只需要在請求中傳遞該JWT加密字符串，並且確保每個服務器實例都可以解密Token並驗證用戶身份。
JWT的優點
無需使用緩存/數據庫來存儲Session ID
JWT的缺點
無法從服務器撤消Token，服務器只能確定Token是否有效
歡迎關注我的公眾號：：一點教程。獲得獨家整理的學習資源和日常干貨推送。
如果您對我的系列教程感興趣，也可以關注我的網站：yiidian.com