原文鏈接： https://blog.csdn.net/z735640642/article/details/94800165
一、背景
在企業發展初期，企業使用的系統很少，通常一個或者兩個，每個系統都有自己的登錄模塊，運營人員每天用自己的賬號登錄，很方便。
但隨着企業的發展，用到的系統隨之增多，運營人員在操作不同的系統時，需要多次登錄，而且每個系統的賬號都不一樣，這對於運營人員
來說，很不方便。於是，就想到是不是可以在一個系統登錄，其他系統就不用登錄了呢？這就是單點登錄要解決的問題。
單點登錄英文全稱Single Sign On，簡稱就是SSO。
它的解釋是：在多個應用系統中，只需要登錄一次，就可以訪問其他相互信任的應用系統。
如圖所示，圖中有4個系統，分別是Application1、Application2、Application3、和SSO。Application1、Application2、Application3沒有登錄模塊，而SSO只有登錄模塊，沒有其他的業務模塊.
當Application1、Application2、Application3需要登錄時，將跳到SSO系統，SSO系統完成登錄，其他的應用系統也就隨之登錄了。這完全符合我們對單點登錄（SSO）的定義。
二、技術實現
在說單點登錄（SSO）的技術實現之前，我們先說一說普通的登錄認證機制。
如上圖所示，我們在瀏覽器（Browser）中訪問一個應用，這個應用需要登錄，我們填寫完用戶名和密碼後，完成登錄認證。
這時，我們在這個用戶的session中標記登錄狀態爲yes（已登錄），同時在瀏覽器（Browser）中寫入Cookie，這個Cookie是這個用戶的唯一標識。
下次我們再訪問這個應用的時候，請求中會帶上這個Cookie，服務端會根據這個Cookie找到對應的session，通過session來判斷這個用戶是否登錄。
如果不做特殊配置，這個Cookie的名字叫做jsessionid，值在服務端（server）是唯一的。
同域下的單點登錄
一個企業一般情況下只有一個域名，通過二級域名區分不同的系統。比如我們有個域名叫做：a.com，同時有兩個業務系統分別爲：app1.a.com和app2.a.com。我們要做單點登錄（SSO），需要一個登錄系統，叫做：sso.a.com。
我們只要在sso.a.com登錄，app1.a.com和app2.a.com就也登錄了。
通過上面的登陸認證機制，我們可以知道，在sso.a.com中登錄了，其實是在sso.a.com的服務端的session中記錄了登錄狀態，同時在瀏覽器端（Browser）的sso.a.com下寫入了Cookie。
那麼我們怎麼才能讓app1.a.com和app2.a.com登錄呢？這裏有兩個問題：
Cookie是不能跨域的，我們Cookie的domain屬性是sso.a.com，在給app1.a.com和app2.a.com發送請求是帶不上的。
sso、app1和app2是不同的應用，它們的session存在自己的應用內，是不共享的。
那麼我們如何解決這兩個問題呢？針對第一個問題，sso登錄以後，可以將Cookie的域設置爲頂域，即.a.com，這樣所有子域的系統都可以訪問到頂域的Cookie。
我們在設置Cookie時，只能設置頂域和自己的域，不能設置其他的域。比如：我們不能在自己的系統中給baidu.com的域設置Cookie。
Cookie的問題解決了，我們再來看看session的問題。我們在sso系統登錄了，這時再訪問app1，Cookie也帶到了app1的服務端（Server），app1的服務端怎麼找到這個Cookie對應的Session呢？
這裏就要把3個系統的Session共享，如圖所示。共享Session的解決方案有很多，例如：Spring-Session。這樣第2個問題也解決了。
同域下的單點登錄就實現了，但這還不是真正的單點登錄。
不同域下的單點登錄
同域下的單點登錄是巧用了Cookie頂域的特性。如果是不同域呢？不同域之間Cookie是不共享的，怎麼辦？
這裏我們就要說一說CAS流程了，這個流程是單點登錄的標準流程。
上圖是CAS官網上的標準流程，具體流程如下：
用戶訪問app系統，app系統是需要登錄的，但用戶現在沒有登錄。
跳轉到CAS server，即SSO登錄系統，以後圖中的CAS Server我們統一叫做SSO系統。 SSO系統也沒有登錄，彈出用戶登錄頁。
用戶填寫用戶名、密碼，SSO系統進行認證後，將登錄狀態寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie。
SSO系統登錄完成後會生成一個ST（Service Ticket），然後跳轉到app系統，同時將ST作爲參數傳遞給app系統。
app系統拿到ST後，從後臺向SSO發送請求，驗證ST是否有效。
驗證通過後，app系統將登錄狀態寫入session並設置app域下的Cookie。
至此，跨域單點登錄就完成了。以後我們再訪問app系統時，app就是登錄的。接下來，我們再看看訪問app2系統時的流程。
用戶訪問app2系統，app2系統沒有登錄，跳轉到SSO。
由於SSO已經登錄了，不需要重新登錄認證。
SSO生成ST，瀏覽器跳轉到app2系統，並將ST作爲參數傳遞給app2。
app2拿到ST，後臺訪問SSO，驗證ST是否有效。
驗證成功後，app2將登錄狀態寫入session，並在app2域下寫入Cookie。
這樣，app2系統不需要走登錄流程，就已經是登錄了。SSO，app和app2在不同的域，它們之間的session不共享也是沒問題的。
那麼，SSO系統登錄後，跳回原業務系統時，帶了個參數ST，業務系統還要拿ST再次訪問SSO進行驗證，覺得這個步驟有點多餘。
他想SSO登錄認證通過後，通過回調地址將用戶信息返回給原業務系統，原業務系統直接設置登錄狀態，這樣流程簡單，也完成了登錄，不是很好嗎？
其實這樣問題時很嚴重的，如果我在SSO沒有登錄，而是直接在瀏覽器中敲入回調的地址，並帶上僞造的用戶信息，是不是業務系統也認爲登錄了呢？這是很可怕的。
三、單點登陸總結
單點登錄（SSO）的所有流程都介紹完了，原理大家都清楚了。總結一下單點登錄要做的事情：
單點登錄（SSO系統）是保障各業務系統的用戶資源的安全 。
各個業務系統獲得的信息是，這個用戶能不能訪問我的資源。
單點登錄，資源都在各個業務系統這邊，不在SSO那一方。 用戶在給SSO服務器提供了用戶名密碼後，作爲業務系統並不知道這件事。SSO隨便給業務系統一個ST，那麼業務系統是不能確定這個ST是用戶僞造的，還是真的有效，所以要拿着這個ST去SSO服務器再問一下，這個用戶給我的ST是否有效，是有效的我才能讓這個用戶訪問。
四、CAS原理介紹
體系結構
從結構體系看，CAS 包括兩部分： CAS Server 和 CAS Client 。
CAS Server負責完成對用戶的認證工作 ，會爲用戶簽發兩個重要的票據：登錄票據（TGT）和服務票據（ST）來實現認證過程, CAS Server需要獨立部署 。
CAS Client負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。準確地來說，它以Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 ServiceTicket（服務票據，由 CAS Server發出用於標識目標服務）。CAS Client 與受保護的客戶端應用部署在一起。
由上可知，它符合SSO中的角色架構，如下：
＊ User （多個）
＊ Web 應用（多個CAS Client—與Web應用部署在一起）
＊ SSO 認證中心（ 一個CAS Server—獨立部署）
核心票據
CAS的核心就是其Ticket，及其在Ticket之上的一系列處理操作。CAS的主要票據有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0(基礎模式)協議中就有的票據，PGT、PGTIOU、PT是CAS2.0(代理模式)協議中有的票據。這裏主要介紹CAS1.0—基礎模式中的幾種票據。
TGT（Ticket Grangting Ticket）
TGT是CAS爲用戶簽發的登錄票據，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。TGT封裝了Cookie值以及此Cookie值對應的用戶信息。用戶在CAS認證成功後，生成一個TGT對象，放入自己的緩存（Session）；同時，CAS生成cookie（叫TGC，個人理解，其實就是TGT的SessionId），寫入瀏覽器。TGT對象的ID就是cookie的值，當HTTP再次請求到來時，如果傳過來的有CAS生成的cookie，則CAS以此cookie值（SessionId）爲key查詢緩存中有無TGT（Session），如果有的話，則說明用戶之前登錄過，如果沒有，則用戶需要重新登錄。
TGC （Ticket-granting cookie）
上面提到，CAS-Server生成TGT放入自己的Session中，而TGC就是這個Session的唯一標識（SessionId），以Cookie形式放到瀏覽器端，是CAS Server用來明確用戶身份的憑證。（如果你理解Session的存放原理的話就很好理解）
ST（ServiceTicket）
ST是CAS爲用戶簽發的訪問某一服務票據。用戶訪問service時，service發現用戶沒有ST，則要求用戶去CAS獲取ST。用戶向CAS發出獲取ST的請求，如果用戶的請求中包含cookie，則CAS會以此cookie值爲key查詢緩存中有無TGT，如果存在TGT，則用此TGT簽發一個ST，返回給用戶。用戶憑藉ST去訪問service，service拿ST去CAS驗證，驗證通過後，允許用戶訪問資源。
爲了保證ST的安全性：ST 是基於隨機生成的，沒有規律性。而且，CAS規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。而且，CAS 協議規定ST只能使用一次，無論 Service Ticket 驗證是否成功， CASServer 都會清除服務端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
訪問流程
最後，在單點登錄CAS實現中，是不是隻要TGC就足夠了，不需要ST呢？
當然，不能不要ST。
1. 單點登錄的過程中，第一步應用服務器將請求重定向到認證服務器，用戶輸入賬號密碼認證成功後，只是在瀏覽器和認證服務器之間建立了信任(TGC)，但是瀏覽器和應用服務器之間並沒有建立信任
2. ST是CAS認證中心認證成功後返回給瀏覽器，瀏覽器帶着它去訪問應用服務器，應用服務器再憑它去認證中心驗證你這個用戶是否合法。只有這樣，瀏覽器和應用服務器才能建立信任的會話。
3. 而TGC的作用主要是用於實現單點登錄，就是當瀏覽器要訪問應用服務器2時，應用服務器2也會重定向到認證服務器，但是此時由於TGC的存在，認證服務器信任了該瀏覽器，就不需要用戶再輸入賬號密碼了，直接返回給瀏覽器ST，重複2中的步驟。