看過不少JWT和單點登錄系統的文章，自己也算略知一二。
這裡就根據自己的實際開發經驗談一下我的理解。
大致可以總結為以下三種方案：
1. 純Jwt
2. Jwt + 認證中心Redis
3. Jwt + 認證中心Redis + 多系統Redis
1. 純Jwt 方案
<code>1. 用戶去認證中心登錄，認證中心生成jwt，返回給客戶端。 2. 客戶端攜帶jwt請求多個系統 3. 每個系統各自解析jwt，取出用戶信息。能解析成功就說明jwt有效，繼續處理 自己的業務邏輯。 優點：認證流程簡單，服務端處理速度快。 缺點：因為簡單，所以不安全。jwt一旦下發，有效期內就無法使其主動失效。 一句話總結：認證中心創建Jwt，其他系統解析。/<code>
2.Jwt + 認證中心Redis
<code>1. 用戶去認證中心登錄，認證中心生成jwt，保存到redis並返回給客戶端。 2. 客戶端攜帶jwt去多個系統認證 3. 每個系統只負責從請求中取出jwt, 傳給認證中心。認證解析用戶信息， 並與redis中的jwt校驗，判斷是否有效。然後返回用戶信息給剛才發起驗證請求的系統。 優點：安全性高，服務端能控制jwt主動失效。 缺點：每次請求需要認證的接口，都需要訪問認證中心，耗時略長。 一句話總結：認證中心負責Jwt的創建與解析，其他系統不參與認證邏輯。/<code>
3.Jwt + 認證中心redis + 多系統redis
<code>1. 用戶去認證中心登錄，認證中心生成jwt，保存到redis並返回給客戶端。 2. 客戶端攜帶jwt去多個系統認證 3. 多系統(比如系統A)收到jwt，A解析並取出用戶信息，先判斷自己的A的redis中 有沒有jwt。 3.1 如果有，就合法，a系統可以繼續執行業務邏輯。 3.2 如果沒有就拿著jwt去認證中心驗證。 3.2.1 如果通過，a系統就把這個jwt保存到自己的redis，並設置對應的失效時間。 下次這個jwt再來到a的時候，就不需要去認證中心校驗了。 3.2.2 如果驗證不通過此次請求就不合法，告訴客戶端需要跳轉登錄頁面， 去認證中心登錄，返回步驟1。 優點：安全性高，平均認證過程較快。 缺點：服務端流程複雜，需要考慮jwt的同步問題。比如註銷或重新登錄後，認證中心 刪除舊jwt需要同步給其他系統，其他系統刪除自己保存的jwt。 一句話總結：認證中心創建jwt，其他系統解析並校驗，需要保持jwt同步。/<code>
綜合總結：
方案1才是Jwt的本質。方案2是我基於Jwt的改進，用作我們公司新項目的登錄系統。（個人比較推薦方案3，後續考慮會向方案3轉移）方案3準確說是單點登錄系統的標準流程，只是結合了Jwt。其他2種方案都是偽單點。
備註： 文中使用Redis是為了單個系統集群機器之間能夠“Session共享”。