一、什麼是單點登錄？
單點登錄的英文名叫做：Single Sign On（簡稱SSO）。在初學/以前的時候，一般我們就單系統，所有的功能都在同一個系統上。爲了合理利用資源和降低耦合性，於是把單系統拆分成多個子系統。簡單來說，單點登錄就是在多個系統中，用戶只需一次登錄，各個系統即可感知該用戶已經登錄。
二、多系統登錄的問題
1. Session不共享問題
單系統登錄功能主要是用Session保存用戶信息來實現的，但我們清楚的是：多系統即可能有多個Tomcat，而Session是依賴當前系統的Tomcat，所以系統A的Session和系統B的Session是不共享的。
解決系統之間Session不共享問題有一下幾種方案：
- Tomcat集羣Session全局複製（集羣內每個tomcat的session完全同步）【會影響集羣的性能呢，不建議】
- 根據請求的IP進行Hash映射到對應的機器上（這就相當於請求的IP一直會訪問同一個服務器）【如果服務器宕機了，會丟失了一大部分Session的數據，不建議】
- 把Session數據放在Redis中（使用Redis模擬Session）【建議】。將Session存儲於Redis上，然後將整個系統的全局Cookie Domain設置於頂級域名上，這樣SessionID就能在各個子系統間共享。
2. Cookie跨域的問題
比如說，我們請求 <https://www.google.com/>時，瀏覽器會自動把 goolge 的 Cookie 帶過去給 google 的服務器，而不會把<https://www.baidu.com/>的 Cookie 帶過去給 google 的服務器。這就意味着，由於域名不同，用戶向系統A登錄後，系統A返回給瀏覽器的Cookie，用戶再請求系統B的時候不會將系統 A 的 Cookie 帶過去。
針對Cookie存在跨域問題，有幾種解決方案：
- 服務端將Cookie寫到客戶端後，客戶端對Cookie進行解析，將Token解析出來，此後請求都把這個Token帶上就行了
- 多個域名共享Cookie，在寫到客戶端的時候設置 Cookie 的 domain。
- 將 Token 保存在SessionStroage中（不依賴Cookie就沒有跨域的問題了）。
3. CAS原理 (Central Authentication Service)
如果已經將登錄單獨抽取成系統出來，我們還能這樣玩。現在我們有兩個系統，分別是www.java3y.com和www.java4y.com，一個SSO www.sso.com。
首先，用戶想要訪問系統A www.java3y.com受限的資源(比如說購物車功能，購物車功能需要登錄後才能訪問)，系統A www.java3y.com發現用戶並沒有登錄，於是重定向到 sso 認證中心，並將自己的地址作爲參數。請求的地址如下：
www.sso.com?service=www.java3y.com
sso認證中心發現用戶未登錄，將用戶引導至登錄頁面，用戶進行輸入用戶名和密碼進行登錄，用戶與認證中心建立全局會話（生成一份Token，寫到Cookie中，保存在瀏覽器上）。
隨後，認證中心重定向回系統A，並把Token攜帶過去給系統A，重定向的地址如下：
www.java3y.com?token=xxxxxxx
接着，系統A去sso認證中心驗證這個Token是否正確，如果正確，則系統A和用戶建立局部會話（創建Session）。到此，系統A和用戶已經是登錄狀態了。
此時，用戶想要訪問系統Bwww.java4y.com受限的資源(比如說訂單功能，訂單功能需要登錄後才能訪問)，系統B www.java4y.com發現用戶並沒有登錄，於是重定向到sso認證中心，並將自己的地址作爲參數。請求的地址如下：
www.sso.com?service=www.java4y.com
注意，因爲之前用戶與認證中心 www.sso.com已經建立了全局會話（當時已經把Cookie保存到瀏覽器上了），所以這次系統B重定向到認證中心www.sso.com是可以帶上Cookie的。
認證中心根據帶過來的Cookie發現已經與用戶建立了全局會話了，認證中心重定向回系統B，並把Token攜帶過去給系統B，重定向的地址如下：
www.java4y.com?token=xxxxxxx
接着，系統B去sso認證
- 用戶通過登錄子系統進行用戶登錄；
- 用戶登錄子系統記錄了用戶的登錄狀態、OpenId等信息；
中心驗證這個Token是否正確，如果正確，則系統B和用戶建立局部會話（創建Session）。到此，系統B和用戶已經是登錄狀態了。
看到這裏，其實SSO認證中心就類似一個中轉站。