以下轉載至https://blog.csdn.net/javaloveiphone/article/details/52439613

1)、問：系統A是如何發現該請求需要登錄重定向到認證中心的？
答：用戶通過瀏覽器地址欄訪問系統A，系統A(也可以稱為CAS客戶端)去Cookie中拿JSESSION，即在Cookie中維護的當前回話session的id，如果拿到了，說明用戶已經登錄，如果未拿到，說明用戶未登錄。

2)、問：系統A重定向到認證中心，發送了什麽信息或者地址變成了什麽？
答：假如系統A的地址為http://a:8080/，CAS認證中心的服務地址為http://cas.server:8080/，那麽重點向前後地址變化為：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重點向到認證中心，認證中心拿到了當前訪問客戶端的地址。

3)、問：登錄成功後，認證中心重定向請求到系統A，認證通過令牌是如何附加發送給系統A的？
答：重定向之後的地址欄變成：http://a:8080/?ticket=ST-XXXX-XXX，將票據以ticket為參數名的方式通過地址欄發送給系統A

4)、問：系統A驗證令牌，怎樣操作證明用戶登錄的？
答：系統A通過地址欄獲取ticket的參數值ST票據，然後從後臺將ST發送給CAS server認證中心驗證，驗證ST有效後，CAS server返回當前用戶登錄的相關信息，系統A接收到返回的用戶信息，並為該用戶創建session會話，會話id由cookie維護，來證明其已登錄。

5)、問：登錄B系統，認證中心是如何判斷用戶已經登錄的？
答：在系統A登錄成功後，用戶和認證中心之間建立起了全局會話，這個全局會話就是TGT(Ticket Granting Ticket)，TGT位於CAS服務器端，TGT並沒有放在Session中，也就是說，CAS全局會話的實現並沒有直接使用Session機制，而是利用了Cookie自己實現的，這個Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用戶瀏覽器上。
相關內容分析可以查看：《SSO CAS單點系列》之 實操！輕松玩轉SSO CAS就這麽簡單(相識篇)

用戶發送登錄系統B的請求，首先會去Cookie中拿JSESSION，因為系統B並未登錄過，session會話還未創建，JSESSION的值是拿不到的，然後將請求重定向到CAS認證中心，CAS認證中心先去用戶瀏覽器中拿TGC的值，也就是全局會話id，如果存在則代表用戶在認證中心已經登錄，附帶上認證令牌重定向到系統B。

上面登錄狀態判斷也是這個邏輯。

6)、問：登出的過程，各個系統對當前用戶都做了什麽？
答：認證中心清除當前用戶的全局會話TGT，同時清掉cookie中TGT的id：TGC；
然後是各個客戶端系統，比如系統A、系統B，清除局部會話session，同時清掉cookie中session會話id：jsession

cas sso原理