本文將以通俗易懂的方式闡述單點登錄的流程，在這之前你可以閱讀下比較官方的介紹單點登錄。在閱讀本文章之前，希望你對單點登錄有一定的瞭解。
話不多說，直接上單獨登錄流程：
三個系統
系統A
認證系統B
系統C
-
流程1
請求訪問受保護系統A，系統A對請求進行攔截(Filter)，攔截器會讀取Cookie信息，獲取token(登錄憑證)，調用認證系統B校驗token是否有效，如果token爲空獲取token失效，Filter會將請求重定向到認證系統B的登錄頁面 -
流程2
用戶在認證系統登錄成功後，將token存儲在Cookie中，然後重定向到A系統中，並在將token作爲請求參數(此時瀏覽器中存儲了系統B的Cookie) -
流程3
重定向到系統後A後，Filter攔截到請求參數token，然後對token進校驗，認證通過，將token存儲Cookie中(此時瀏覽器中存儲了系統B，系統A的Cookie) -
流程4
用戶請求系統C，Filter攔截到用戶無token信息，將請求轉發到認證系統B -
流程5
請求轉發到認證系統B後，系統B也會經過Filter，系統B發現當前Cookie中有token且有效，將請求又重定向到系統C，並將當前token作爲請求參數 -
流程6
流程6和流程3一樣，Filter獲取到token後，對token進行認證然後存儲到Cookie中
在訪問受保護資源時，都會從Cookie中讀取token，驗證權限。李姐單點登錄的關鍵在於瀏覽器中存儲的是A、B、C三個系統的Cookie。
Filter的作用：
首先從Cookie中獲取token，然後再從請求參數中獲取token，然後對token進行校驗，校驗成功，將token存儲到Cookie中，其實3個系統使用的Filter都是同一個。系統A、C對token進行認證也是調用的是認證系統B的服務。
可能有的用戶會認爲認證系統B在轉發到系統A、C的時候直接將token做請求參數不安全？
解決方式：可以採用OAuth2.0的授權碼模式，在轉發時攜帶參數爲AppId，通過AppId獲取token，然後將token存儲到Cookie
推薦一個簡單易懂的開源SSO
如有對單點登錄李姐出錯或者不合理地地方，歡迎各位指出！！！