為什麼需要單點登錄
單點登錄SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登錄後，就不用在其他系統中登錄，也就是用戶的一次登錄能得到其他所有系統的信任。
單點登錄在大型網站裡使用得非常頻繁，例如，阿里旗下有淘寶、天貓、支付寶等網站，還有背後的成百上千的子系統，用戶一次操作或交易可能涉及到幾十個子系統的協作，如果每個子系統都需要用戶認證，不僅用戶會瘋掉，各子系統也會為這種重複認證授權的邏輯搞瘋掉。
所以，單點登錄要解決的就是，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
單點登錄的來源
1.早期的單機部署：web單系統應用
早期我們開發web應用都是所有的包放在一起打成一個war包放入tomcat容器來運行的,所有的功能,所有的業務,後臺管理,門戶界面,都是由這一個war來支持的,這樣的單應用,也稱之為巨石應用,因為十分不好擴展和拆分。
在巨石應用下,用戶的登錄以及權限就顯得十分簡單,用戶登錄成功後,把相關信息放入會話中,HTTP維護這個會話,再每次用戶請求服務器的時候來驗證這個會話即可,大致可以用下圖來表示:
驗證登錄的這個會話就是session,維護了用戶狀態,也就是所謂的HTTP有狀態協議,我們經常可以在瀏覽器中看到JSESSIONID,這個就是用來維持這個關係的key。
2.分佈式集群部署
由於網站的訪問量越來也大，單機部署已經是巨大瓶頸，所以才有了後來的分佈式集群部署。例如：如果引入集群的概念,1單應用可能重新部署在3臺tomcat以上服務器,使用nginx來實現反向代理, 此時,這個session就無法在這3臺tomcat上共享,用戶信息會丟失，所以不得不考慮多服務器之間的session同步問題，這就是單點登錄的來源。
單點登錄的原理和實現
單點登錄的實現方案，一般就包含：Cookies，Session同步，分佈式Session方式，目前的大型網站都是採用分佈式Session的方式。我先從cookie的實現談起，你就能很清楚的知道為什麼需要分佈式session方式實現單點登錄。
1.基於Cookie的單點登錄
最簡單的單點登錄實現方式，是使用cookie作為媒介，存放用戶憑證。 用戶登錄父應用之後，應用返回一個加密的cookie，當用戶訪問子應用的時候，攜帶上這個cookie，授權應用解密cookie並進行校驗，校驗通過則登錄當前用戶。
不難發現以上方式把信任存儲在客戶端的Cookie中，這種方式很容易令人質疑：
- Cookie不安全
- 不能跨域實現免登
對於第一個問題，通過加密Cookie可以保證安全性，當然這是在源代碼不洩露的前提下。如果Cookie的加密算法洩露，攻擊者通過偽造Cookie則可以偽造特定用戶身份，這是很危險的。 對於第二個問題，不能跨域實現免登更是硬傷。所以，才有了以下的分佈式session方案。
分佈式session方式實現單點登錄
例如阿里有很多系統分割為多個子系統，獨立部署後，不可避免的會遇到會話管理的問題，類似這樣的電商網站一般採用分佈式Session實現。
再進一步可以根據分佈式Session，建立完善的單點登錄或賬戶管理系統。
流程運行：
（1） 用戶第一次登錄時，將會話信息（用戶Id和用戶信息），比如以用戶Id為Key，寫入分佈式Session；
（2） 用戶再次登錄時，獲取分佈式Session，是否有會話信息，如果沒有則調到登錄頁；
（3） 一般採用Cache中間件實現，建議使用Redis，因此它有持久化功能，方便分佈式Session宕機後，可以從持久化存儲中加載會話信息；
（4） 存入會話時，可以設置會話保持的時間，比如15分鐘，超過後自動超時；
結合Cache中間件，實現的分佈式Session，可以很好的模擬Session會話。
總結：
以上分別從單點登錄的原理、來源、實現機制來完整的解讀單點登錄。
實現單點登錄說到底就是要解決如何產生和存儲那個信任，再就是其他系統如何驗證這個信任的有效性，因此要點也就以下兩個：
- 存儲信任
- 驗證信任
存儲信任建議可以採用分佈式文件存儲redis來實現。
閱讀更多 優知學院 的文章
