什么是SSO？

Web應用系統的演化總是從簡單到復雜，從單功能到多功能模塊再到多子系統方向發展。 圖片描述：

當前的大中型Web互聯網應用基本都是多系統組成的應用群，由多個web系統協同為用戶提供服務。

多系統應用群，必然意味著各系統間既相對獨立，又保持著某種聯系。

獨立，意味著給用戶提供一個相對完整的功能服務，比如C2C商城，比如B2C商城。聯系，意味著從用戶角度看，不管企業提供的服務如何多樣化、系列化，在用戶看來，仍舊是一個整體，用戶體驗不能受到影響。

譬如用戶的賬號管理，用戶應該有一個統一賬號，不應該讓用戶在每個子系統分別注冊、分別登錄、再分別登出。系統的復雜性不應該讓用戶承擔。 圖片描述：

登錄用戶使用系統服務，可以看做是一次用戶會話過程。在單Web應用中，用戶登錄、登錄狀態判斷、用戶登出等操作，已有很常規的解決方案實現。

在多系統應用群中，這個問題就變得有些復雜，以前本不是問題的問題，現在可能就變成了一個重大技術問題。我們要用技術手段，屏蔽系統底層本身的技術復雜性，給用戶提供自然超爽的用戶體驗。

這就是我們所說的單點登錄問題，即SSO(Single Sign On)。當然，我們這里主要討論的是Web系統，確切地講，應該叫Web SSO。 實際案例分析

下面我們來看一個現實中SSO的例子，例如阿里系統：

阿里目前給用戶提供的服務很龐大，種類也很繁多，我們看幾個典型系統應用：www.taobao.com 淘寶應用、www.tmall.com 天貓應用、 www.alitrip.com 阿里旅游。這些應用，當用戶訪問時，都需要登錄

顯然，對用戶來說，他不希望每個子應用分別登錄，因為這都是阿里服務，在用戶看來，就相當于一個大系統。

當我在一個應用如淘寶上登錄后，再訪問阿里旅游、天貓等其它系統，我們發現，系統都顯示已登錄狀態。

當在任意一系統退出登錄后，再刷新訪問其它系統，均已顯示登出狀態。

可以看出，阿里實現了SSO。實際上，幾乎所有提供復雜服務的互聯網公司，都實現了SSO，如阿里、百度、新浪、網易、騰訊、58…

SSO問題，是大中型Web應用經常碰到的問題，是java架構師需要掌握的必備技能之一，中高級以上Web工程師都應對它有個了解。 SSO技術難點

SSO有啥技術難點？為什么我們不能像解決單Web應用系統登錄那樣自然解決？為說清楚這一問題，我們得先了解下單應用系統下，用戶登錄的解決方案。

我們討論的應用是Web應用，大家知道，對于Web應用，系統是Browser/Server架構，Browser和Server之間的通信協議是HTTP協議。

HTTP是一個無狀態協議。即對服務器來說，每次收到的瀏覽器HTTP請求都是單一獨立的，服務器并不考慮兩次HTTP請求是否來自同一會話，即HTTP協議是非連接會話狀態協議。

對于Web應用登錄，意味著登錄成功后的后續訪問，可以看做是登錄用戶和服務端的一次會話交互過程，直到用戶登出結束會話。

如何在非連接會話協議之上，實現這種會話的管理？ 我們需要額外的手段。

通常有兩種做法，一種是通過使用HTTP請求參數傳遞，這種方式對應用侵入性較大，一般不使用。

另一種方式就是通過cookie。

cookie是HTTP提供的一種機制，cookie代表一小撮數據。服務端通過HTTP響應創建好cookie后，瀏覽器會接收下來，下次請求會自動攜帶上返回給服務端。 利用這個機制，我們可以實現應用層的登錄會話狀態管理。例如我們可以把登錄狀態信息保存在cookie中，這是客戶端保存方式。

由于會話信息在客戶端，需要維護其安全性、需要加密保存、攜帶量會變大，這樣會影響http的處理效率，同時cookie的數據攜帶量也有一定的限制。

比較好的方式是服務端保存，cookie只保存會話信息的句柄。即在登錄成功后，服務端可以創建一個唯一登錄會話，并把會話標識ID通過cookie返回給瀏覽器，瀏覽器下次訪問時會自動帶上這個ID，服務端根據ID即可判斷是此會話中的請求，從而判斷出是該用戶，這種操作直到登出銷毀會話為止。

令人高興的是，我們使用的Web應用服務器一般都會提供這種會話基礎服務，如Tomcat的session機制。也就是說，應用開發人員不必利用Cookie親自代碼實現會話的創建、維護和銷毀等整個生命周期管理，這些內容服務器Session已經提供好了，我們只需正確使用即可。

當然，為了靈活性和效率，開發人員也可直接使用cookie實現自己的這種會話管理。

對于Cookie，處于安全性考慮，它有一個作用域問題，這個作用域由屬性Domain和Path共同決定的。也就是說，如果瀏覽器發送的請求不在此Cookie的作用域范圍內，請求是不會帶上此Cookie的。

Path是訪問路徑，我們可以定義/根路徑讓其作用所有路徑，Domain就不一樣了。我們不能定義頂級域名如.com，讓此Cookie對于所有的com網站都起作用，最大范圍我們只能定義到二級域名如.taobao.com，而通常，企業的應用群可能包含有多個二級域名，如taobao.com、tmail.com、alitrip.com等等。

這時，解決單系統會話問題的Cookie機制不起作用了，多系統不能共享同一會話，這就是問題的所在！

當然，有的同學會說：我把所有的應用統一用三級域名來表示，如a.taobao.com、b.taobao.com、c.taobao.com或干脆用路徑來區分不同的應用如www.taobao.com/a、www.taobao.com/b、www.taobao.com/c，這樣cookie不就可以共享了么？

事實是成立的，但現實應用中，多域名策略是普遍存在的，也有商業角度的考慮，這些我們必須要面對。

退一步講，即使cookie可以共享了，服務端如何識別處理這個會話？這時，我們是不能直接使用服務器所提供的Session機制的，Session是在單一應用范圍內，共享Session需要特殊處理。

更復雜的情況是，通常這些子系統可能是異構的，session實現機制并不相同，如有的是Java系統，有的是php系統。共享Session對原系統入侵性很大。 至此，SSO技術問題這里講清楚了。那我們有沒有更好的通用解決方案？答案肯定是有的，但比較復雜，這也是我們專題討論的理由?？傮w來說，我們需要一個中央認證服務器，來統一集中處理各子系統的登錄請求。這是入門，后續會有系列文章深層次探討。

作者： 手插口袋_ 鏈接：http://www.imooc.com/article/3555 來源：慕課網