什麼是JWT令牌認證？

當下，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