本篇和大家分享、探討SSO（單點登錄），內容涉及SSO的定義、表現、原理、實現細節等方面的闡述@mikechen

一、單點登錄介紹

單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。

單點登錄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方式實現單點登錄。

基于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來實現。

閱讀原文：原文鏈接