Jwt單點登錄的三種方案

看過不少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>

綜合總結：

備註： 文中使用Redis是為了單個系統集群機器之間能夠“Session共享”。

關鍵字: 客戶端 三種 方案