單點登錄系統
單點登錄系統保存了用戶的登錄名和密碼，上網用戶在單點登錄系統中認證成功后，就可以直接登錄各個業務系統。
1. 用戶使用單點登錄系統的登錄界面，輸入用戶名和密碼登錄成功后， 單點登錄系統為用戶瀏覽器安裝一個cookie，cookie的值是一個全局唯 一的字符串 （下文稱為ticket），理論上這個唯一值永遠不能重復，用來 標識用戶成功的登錄請求。同一個用戶，在同一個時刻登錄兩次，得到的 ticket值 應該完全不同。 2. 用戶訪問業務系統時，如果當前用戶已經在業務系統中登錄，那么訪問 業務系統的cookie中，會攜帶單點登錄ticket，業務系統根據此ticket，去 單點登錄系統中查詢用戶是否在線，如果在，就允許繼續訪問，否則就執行 注銷操作 3. 用戶在任意一個業務系統中執行注銷操作時，業務系統在攔截注銷操作， 並且與單點登錄系統聯動，在單點登錄系統中完成注銷后，再跳轉回業務系 統的注銷界面
優點
1. 單點登錄系統的整套攔截和轉發流程，可以封裝成為公共組件，代碼修改量少
2. 所有業務系統都可以使用上述方案增加與單點登錄系統的聯動功能
缺點
上述單點登錄功能，依賴瀏覽器的cookie功能，如果瀏覽器不支持cookie，將無法使用
關於這個方案的安全性問題，可以通過定期更新ticket值，或每次訪問都生成不同的ticket值來進行規避。
因為涉及對於單點登錄系統的大量訪問，所以會使得單點登錄系統成為瓶頸，我們項目中采用性能更高的網絡協議，
例如UDP協議進行在線狀態交互，因為UDP報文頭部較小，報文有效內容比例大，同時報文長度短，比現有的HTTP協議性能高2個數量級，每秒支撐1000次查詢請求，是沒有問題的.
我們使用了JWT來做用戶的狀態保持機制和數據認證
因為JWT的token是保存在瀏覽器端的,不影響服務器開銷,
多台服務器也可以使用,不需要多次登錄,會保存在瀏覽器一
個空間里,這個空間加密性比cookie強,即使cookie被截獲,
也不會泄露用戶信息,比較安全.
JWT一般會采用消息認證機制:在哈希算法基礎上混入秘鑰,
防止哈希算法被破解, 避免簽名被偽造,效率比較高.
JWT白名單
在用戶完成修改密碼操作時. 將該用戶加入到白名單中,
先根據用戶身份的唯一標識判斷用戶是否在白名單中,如
果在,說明用戶在token有效期內已經修改過一次密碼, 現
在就需要先刪除用戶白名單中的token數據,用戶修改完密
碼后, 需要讓用戶重新進行登錄生成新的access_token返
回給客戶端,調用生成token的工具生成access_token(訪
問token)的數據,判斷用戶是否有對應的白名單,如果有則將
該token值存入到redis數據庫的白名單中.
當用戶登錄成功后,再進行用戶認證,在驗證token成功后,
對該用戶的白名單進行驗證,判斷該用戶是否在白名單中,
如果在,則驗證token是否在白名單中,如果在則允許用戶訪問,
如果不在則不允許用戶訪問, 返回錯誤
JWT黑名單
關於登錄狀態信息續簽的問題。比如設置token的有效期為一個小時，
那么一個小時后，如果用戶仍然在這個web應用上，這個時候當然不
能指望用戶再登錄一次。所以我們在每次用戶發出請求的時候都返回
一個新的token，前端再用這個新的token來替代舊的，這樣每一次請
求都會刷新token的有效期。但是這樣，需要頻繁的生成token。另外
一種方案是使用Js來動態續簽。判斷還有多久這個token會過期，在
token快要過期時，返回一個新的token。
用戶主動注銷，后台無法讓用戶強制下線。JWT並不支持用戶主動退
出登錄，當然，可以在客戶端刪除這個token，但在別處使用的token
仍然可以正常訪問。為了支持注銷和后台主動強制讓用戶下線， 我們在
項目中的方案是在注銷時將該token加入黑名單。當用戶發出請求后，
如果該token在黑名單中，則阻止用戶的后續操作，返回Invalid token
錯誤。對於名單的維護可以使用redis，token的過期時間和redis中數
據的存活時間保持一致。