JWT單點登入的三種解決方案

1. 純jwt

2. jwt + 認證中心redis

3. jwt + 認證中心redis + 多系統redis

1. 使用者去認證中心登入，認證中心生成jwt，返回給客戶端。

2. 客戶端攜帶jwt請求多個系統 
3. 每個系統各自解析jwt，取出使用者資訊。能解析成功就說明jwt有效，繼續處理自己的業務邏輯。
（所有系統的jwt金鑰保持一致才能各自解析成功）
優點：認證流程簡單，服務端處理速度快。
缺點：因為簡單，所以不安全。jwt一旦下發，有效期內就無法使其主動失效。

一句話總結：認證中心建立jwt，其他系統解析。

1. 使用者去認證中心登入，認證中心生成jwt，儲存到redis並返回給客戶端。

2. 客戶端攜帶jwt去多個系統認證 
3. 每個系統只負責從請求中取出jwt, 傳給認證中心。認證解析使用者資訊，
並與redis中的jwt校驗，判斷是否有效。然後返回使用者資訊給剛才發起驗證請求的系統。
優點：安全性高，服務端能控制jwt主動失效。
缺點：每次請求需要認證的介面，都需要訪問認證中心，耗時略長。

一句話終結：認證中心負責jwt的建立與解析，其他系統不參與認證邏輯。

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同步。

方案2是我基於jwt的改進，用作我們公司新專案的登入系統。

（個人比較推薦方案3，後續考慮會向方案3轉移）

方案3準確說是單點登入系統的標準流程，只是結合了jwt。其他2種方案都是偽單點。

備註： 文中使用redis是為了單個系統集群機器之間能夠「session共享」。

單點登入解決方案

本文只是簡述單點登入解決方案，系統其他方面均省略 如上圖 系統基本架構 fr與es分為兩個不同的子專案，前端請求均通過訪問fr，由fr通過httpurlconnection訪問es 賦能層 fr主要作用為登入鑑權。大致請求流程如下 1 password md5單向加密成新的password 1 如 ...

stricky footer的三種解決方案詳解

stricky footer設計是最古老和最常見的效果之一，我們都曾經歷過類似的情景 如果頁面內容不夠長的時候，頁尾塊貼上在底部 如果內容足夠長時，頁尾塊會被內容向下推送。這些天做vue express實戰的練習，跟著黃軼老師倒是認識了stricky footer，就認真的了解學習了一下，但是前兩天...

單點登入的三種方式

單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用者一次操作或交易可能涉及到幾十個...