CAS是实现了CAS 中心认证服务协议（应用层协议）的一个开源软件实现
百度词条上的协议描述图（有点粗不够明确）
对照着看我觉得下图更能清晰的说明协议流程
，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service(web浏览器要请求的CAS Client保护下的资源的url) 和 Ticket(AccessToken)
，如果没有，则说明当前用户尚未登录，于是CAS Client要求 web浏览器将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便让流程记住后用户登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Ticket票据（AccessToken），并缓存以待将来验证，之后CAS Server响应web浏览器，通知浏览器自动重定向到 Service（原来要请求的资源的url） 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC）(TGC就是保存了登录成功后在CAS Server上的Session会话的 sessionId的那么个cookie值)，CAS Client 在拿到 Service(重定向资源url地址) 和新产生的 Ticket（AccessToken（身份合法象征的访问令牌）） 过后，当web浏览器将向CAS Client再次请求原来想要请求的资源并附加上AccessToken 值和包含了sessionId的 cookie值后，CASClient的到这个请求后会 在第 6,7步中与向 CAS Server 进行身份核实，以确保 要请求的资源及 用户身份令牌Ticket（AccessToken ） 的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，确保，ST (AccessToken)和 TGC(SessionId做在的cookie值) 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket （AccessToken值）的验证的过程对于用户（webBrowser）浏览器来说是透明的。
篇外话提：
CAS Client 应用其实是受保护的资源所在的应用服务（CAS Client功能其实和受保护资源提供服务功能是要集成在一起的），CAS 协议要求受保护的资源服务是放在CAS Client客户端应用处的，这是CAS和OAuth2.0 协议的本质区别！OAuth2.0要求受保护的资源是放在OAuth的资源服务器处，并不是放在OAuth2.0协议的客户端应用处！同样是保护资源但是机制理念是不同的，CAS要求受保护的资源是CAS客户端应用处存放的，
OAuth2.0 要求受保护的资源是放在OAuth2.0 中规定的资源服务器处存放的，通常OAuth2.0 中的授权服务器和资源服务器在现实实现中融为一体了！也就是说OAuth2.0的（授权服务器+ 资源服务器）一体化服务器负责鉴权和身份认证！
而CAS体系中CAS Server服务器负责身份认证（集中式身份认证，本质上是单点登录的精神所在）中央认证服务器
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档