一文了解web無狀態會話token技術JWT

前言

目前web開發先後端已經算很是的普及了。先後端分離要求咱們對用戶會話狀態要進行一個無狀態處理。咱們都知道一般管理用戶會話是session。用戶每次從服務器認證成功後，服務器會發送一個sessionid給用戶，session是保存在服務端 的，服務器經過session辨別用戶，而後作權限認證等。那如何才知道用戶的session是哪一個？這時候cookie就出場了，瀏覽器第一次與服務器創建鏈接的時候，服務器會生成一個sessionid返回瀏覽器，瀏覽器把這個sessionid存儲到cookie當中，之後每次發起請求都會在請求頭cookie中帶上這個sessionid信息，因此服務器就是根據這個sessionid做爲索引獲取到具體session。

痛點

上面的場景會有一個痛點。對於先後端分離來講。好比前端都是部署在一臺服務器的nginx上，後端部署在另外一臺服務器的web容器上。甚至 前端不能直接訪問後端，中間還加了一層代理層。

大概以下所示：

也就是說先後端分離在應用解耦後增長了部署的複雜性。一般用戶一次請求就要轉發屢次。若是用session 每次攜帶sessionid 到服務器，服務器還要查詢用戶信息。同時若是用戶不少。這些信息存儲在服務器內存中，給服務器增長負擔。還有就是CSRF（跨站僞造請求***）***，session是基於cookie進行用戶識別的, cookie若是被截獲，用戶就會很容易受到跨站請求僞造的***。還有就是sessionid就是一個特徵值，表達的信息不夠豐富。不容易擴展。並且若是你後端應用是多節點部署。那麼就須要實現session共享機制。不方便集羣應用。

什麼是JWT

因此JSON WEB TOKEN（如下稱JWT）能夠解決上面的問題。JWT仍是一種token。token 是服務器頒發給客戶端的。就像戶籍管理部門給你發的身份證同樣。你拿着這個證件就能去其餘部門辦事。其餘部門驗證你這個身份證是否過時，是否真假。不用每次都讓戶籍來承認。同時token 自然防止CSRF***。並且JWT能夠攜帶一些不敏感的用戶信息。這樣服務器不用每次都去查詢用戶信息。開箱即用，方便服務器處理鑑權邏輯。

是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519)。該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登陸（SSO）場景。

JWT的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也能夠增長一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

JWT的特色：

• 簡潔(Compact): 能夠經過URL，POST參數或者在HTTP header發送，由於數據量小，傳輸速度也很快
• 自包含(Self-contained)：負載中包含了全部用戶所須要的信息，避免了屢次查詢數據庫或 緩存

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT消息結構：

JWT有3個組成部分，分別是

• 頭部（header) 聲明類型以及加密算法 如 {"alg":"HS256","typ":"JWT"} 用Base64進行了處理
• 載荷（payload) 攜帶一些用戶身份信息，用戶id，頒發機構，頒發時間，過時時間等。用Base64進行了處理。這一段實際上是明文，因此必定不要放敏感信息。
• 簽證（signature) 簽名信息，使用了自定義的一個密鑰而後加密後的結果，目的就是爲了保證簽名的信息沒有被別人改過，這個通常是讓服務器驗證的。

從上面的例子能夠看出來JWT的規則是這樣的 <header>.<payload>.<signature>三部分經過"."進行拼接 。JWT.io提供解析的方法 咱們能夠拿上面那個token去玩一玩

因此JWT不是簡單的token，比session+cookie機制更加豐富。應用場景更加豐富。

JWT不足之處：

JWT並非完美的。

1. 好比說有可能一個用戶同時出現兩個可用的token狀況。
2. 還有若是失效過時瞭如何進行續期的問題。
3. 一樣會出現token被盜用的問題。
4. 註銷如何讓token失效的問題。
5. 用戶信息修改讓token同步的問題。

本文簡單說明了一下JWT，爲了不篇幅過長會在下一篇將對上面JWT這些缺陷進行實際解決方案的解讀。