有個項目可能要用到單點登錄，以前也搭過cas的單點登錄，公司用的是redis檢查sessionId的方式單點登錄。因爲以前的cas比較久遠，忘記了很多，所有有了疑惑，redis的單點登錄和cas的單點登錄有什麼區別，爲什麼redis的那麼簡單，還沒替換掉cas的呢。這裏做一個簡單的比較，方便以後的理解。
首先，簡單說下redis實現單點登錄的方式，其實用redis甚至直接用數據庫都可以完成這項任務，只是如果登錄比對數據放在數據庫中，也就意味着攔截器中的邏輯，每次比對都要從數據庫裏讀取用戶信息，這加大了服務器和數據庫的性能開銷。如果求簡單，而且交互很少的情況下，也可以把sessionID放在數據庫中。
Redis或數據庫模式下的單點登錄：
其實不管是redis中，還是數據庫中，都只是一個存放 sessionID的工具罷了，具體的做法是
1.A用戶登錄的時候，登錄成功，在redis或者數據庫中保存用戶信息（賬戶名等），和sessionID（該值是每個瀏覽器第一次訪問都會生成的一個唯一值，可以確認登錄身份）。
2.A用戶繼續使用或者使用同一瀏覽器登錄其他子功能點時。可以在攔截器中檢查，用戶名和sessionID與前臺傳過來的sessionID是否一致，如果一致，繼續訪問。這一步也可以做到如果sessionID一樣的話，可以免登陸直接進入其他子功能頁，這也是單點登錄的功能之一。
3.B用戶使用A用戶的賬號登錄，登錄成功，則更新sessionID。
4.這時，A 繼續訪問的請求到達攔截器，攔截器比對sessionID，發現sessionID對不上，則跳轉到登錄頁面。此時，A被B擠掉了，這就是redis 或者數據庫模式下，簡單的單點登錄的邏輯。
CAS下完成單點登錄：
cas其實就是引入了一個服務端和客戶端的概念，有一個全局的服務端，每個客戶端成功登陸之後，都需要在服務端註冊。此時會有一個在服務端唯一的token。這樣，在每一個客戶端登錄時，因爲都需要在同一個服務端進行驗證，所以，服務端會對配置好的客戶端進行驗證，這樣就能確認身份了。當單點登錄時，因爲有一個明確的服務端的概念，可以在通過在客戶端的配置，達成很多範圍更大的單點登錄功能。比方說，可以設置多瀏覽器下的單點登錄。
區別：
按我總結來說，其實第一種就像是一個門和一個鎖的概念， 每次不同使用者的相同賬號的登陸，都是一個換鎖換鑰匙的過程。先進去的人出來想再進去，發現門鎖和鑰匙對不上，就被趕走了。
cas更像是一種管理員模式，也就是，找一個公證人，他負責保管鎖，給你一把鑰匙。只要是鑰匙對了，一切都OK
所以，在多瀏覽器下，或者大型分佈式下，模塊很多的情況下，cas更適合，因爲如果換了瀏覽器，或者瀏覽器一關，再重新一開，或者多臺服務器的redis和數據庫不是同一個，第一種邏輯就行不通了，因爲sessionID變了或者保存的地方不一致。
如果說，簡單的分佈式項目，redis的單點登錄也完全夠了。
PS:
以下是另一位博主的理解，有些我沒說清楚的地方也可以參考下：
http://375287760.iteye.com/blog/2400976：
cas（單點登錄）
現象：多個系統只需登錄一次，無需重複登錄
原理：授權服務器，被授權客戶端
1、授權服務器（一個）保存了全局的一份session，客戶端（多個）各自保存自己的session
2、客戶端登錄時判斷自己的session是否已登錄，若未登錄，則（告訴瀏覽器）重定向到授權服務器（參數帶上自己的地址，用於回調）
3、授權服務器判斷全局的session是否已登錄，若未登錄則定向到登錄頁面，提示用戶登錄，登錄成功後，授權服務器重定向到客戶端（參數帶上ticket【一個憑證號】）
4、客戶端收到ticket後，請求服務器獲取用戶信息
5、服務器同意客戶端授權後，服務端保存用戶信息至全局session，客戶端將用戶保存至本地session
oauth2（登錄授權）
現象：第三方系統訪問主系統資源，用戶無需將在主系統的賬號告知第三方，只需通過主系統的授權，第三方就可使用主系統的資源（如：APP1需使用微信支付，微信支付會提示用戶是否授權，用戶授權後，APP1就可使用微信支付功能了）
原理：主系統，授權系統（給主系統授權用的，也可以跟主系統是同一個系統），第三方系統
1、第三方系統需要使用主系統的資源，第三方重定向到授權系統
2、根據不同的授權方式，授權系統提示用戶授權
3、用戶授權後，授權系統返回一個授權憑證（accessToken）給第三方系統【accessToken是有有效期的】
4、第三方使用accessToken訪問主系統資源【accessToken失效後，第三方需重新請求授權系統，以獲取新的accessToken】
單一登錄
現象：同一系統，同一用戶在同一時間內只能有一個會話（即一個用戶只有一個在使用的瀏覽器）
原理：
1、把登錄成功的用戶放入session和緩存，緩存中格式：key:userID,value:sessionId
2、用戶訪問資源時，用攔截器（或過濾器）攔截用戶請求，先判斷用戶是否已登錄（根據session判斷），若用戶未登錄，則定向到登錄頁面提示用戶登錄
3、若用戶session已登錄，根據用戶userID取出緩存數據，判斷當前瀏覽器的sessionId與緩存的是否一致，若一致，則繼續訪問
4、若sessionId不一致，則將當期的session數據清空，用戶登出，提示用戶被踢出