以下转载至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