看過不少JWT和單點登錄系統的文章，自己也算略知一二。
這里就根據自己的實際開發經驗談一下我的理解。
大致可以總結為以下三種方案：
1. 純Jwt
2. Jwt + 認證中心redis
3. Jwt + 認證中心Redis + 多系統Redis
1. 純Jwt 方案
1. 用戶去認證中心登錄，認證中心生成jwt，返回給客戶端。
2. 客戶端攜帶jwt請求多個系統
3. 每個系統各自解析jwt，取出用戶信息。能解析成功就說明jwt有效，繼續處理
自己的業務邏輯。
優點：認證流程簡單，服務端處理速度快。
缺點：因為簡單，所以不安全。jwt一旦下發，有效期內就無法使其主動失效。
一句話總結：認證中心創建Jwt，其他系統解析。
2.Jwt + 認證中心Redis
1. 用戶去認證中心登錄，認證中心生成jwt，保存到redis并返回給客戶端。
2. 客戶端攜帶jwt去多個系統認證
3. 每個系統只負責從請求中取出jwt, 傳給認證中心。認證解析用戶信息，
并與redis中的jwt校驗，判斷是否有效。然后返回用戶信息給剛才發起驗證請求的系統。
優點：安全性高，服務端能控制jwt主動失效。
缺點：每次請求需要認證的接口，都需要訪問認證中心，耗時略長。
一句話總結：認證中心負責Jwt的創建與解析，其他系統不參與認證邏輯。
3.Jwt + 認證中心redis + 多系統redis
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同步。
綜合總結：
- 方案1才是Jwt的本質。
- 方案2是我基于Jwt的改進，用作我們公司新項目的登錄系統。
（個人比較推薦方案3，后續考慮會向方案3轉移） - 方案3準確說是單點登錄系統的標準流程，只是結合了Jwt。其他2種方案都是偽單點。
備注： 文中使用Redis是為了單個系統集群機器之間能夠“Session共享”。
