Cas的全稱是Centeral Authentication Service，是對單點登入SSO（Single Sign On）的一種實作。其由Cas Server和Cas Client兩部分組成，Cas Server是核心，而Cas Client通常就對應于我們的應用。一個Cas Server可以對應于多個Cas Client。它允許我們在一個Client進行登入以後無需再讓使用者輸入使用者名和密碼進行認證即可通路其它Client應用。
Cas Server的主要作用是通過發行和驗證Ticket（票）來對使用者進行認證和授權通路Client應用，用于認證的憑證資訊都是由Cas Server管理的。而Cas Client就對應于我們真正的應用，當然其中會使用到Cas相關的類，用于與Cas Server進行互動。官網有兩張圖最能展現Cas的架構和原理。
如你所見，在第一次通路應用app1時，由于沒有登入會直接跳轉到Cas Server去進行登入認證，此時将附帶查詢參數service在Cas Server的登入位址上，表示登入成功後将要跳轉的位址。此時Cas Server檢查到沒有之前成功登入後生成的SSO Session資訊，那麼就會引導使用者到登入頁面進行登入。使用者輸入資訊送出登入請求，Cas Server認證成功後将生成對應的SSO Session，以及名為CASTGC的cookie，該cookie包含用來确定使用者SSO Session的Ticket Granting Ticket（TGT）。之後會生成一個Service Ticket（ST），并将以ticket作為查詢參數名，以該ST作為查詢參數值跳轉到登入時service對應的URL。如：
http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE
之後的操作對使用者來說都是透明的，即不可見的。app1之後将以service和ticket作為查詢參數請求Cas Server對service進行驗證，驗證通過後Cas Server将傳回目前使用者的使用者名等資訊。app1就會給目前使用者生成其自身的Session，以後該使用者以該Session都可以成功的通路app1，而不需要再去請求Cas Server進行認證。當該使用者再去通路app2的時候，由于其在app2上沒有對應的Session資訊，将會跳轉到Cas Server的登入位址，Cas Server此時發現其包含名為CASTGC的cookie，将擷取其中包含的TGT來擷取對應的SSO Session，然後會将使用者重定向到app2對應的位址，以Service Ticket作為查詢參數。之後app2會向Cas Server發送請求校驗該Service Ticket，校驗成功後app2将建立該使用者對應的Session資訊，以後該使用者以該Session就可以自由的通路app2了。
綜上所述，我們知道，各系統之間的單點登入是通過Cas Server生成的SSO Session來交流的，而使用者與實際的應用系統進行互動的時候，各應用系統将建立單獨的Session，以滿足使用者與該系統的互動需求。
（注：本文是基于cas 3.5.2所寫）