CAS中央认证系统
CAS它的全称是Central Authentication Service，它是用来解决单点登录的问题的。假设现在有一个云平台，上面挂了许多子系统或者其它的服务，登录这些子系统或者使用服务的话就都需要使用云平台的账号，这样就不适合在每个子系统或者服务上自己来实现登陆验证，另一种场景是某个企业存在有N多业务系统，但是这些业务各自为政，有着自己的一套用户认证机制，这样业务人员就得记住N多的用户名和密码，不堪其苦。
单点登陆(SSO)就是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它就是来解决上述提到的两个典型问题的。而CAS就是SSO的一个可靠的具体实现，它是由耶鲁大学提出的。
目前Web系统上主流有两种基础的认证方式，一种是基于Session-Cookie的传统方式，像Tomcat就已经内置了这个方式，我们几乎可以不需要另外再"加料"，虽然HTTP是无状态的，我们用cookie存储了SessionID来模拟有状态的行为，用空间换时间；另一种是基于Token的JWT，登陆成功后服务端返回一个Token给前端，前端请求需要认证的接口的时候都带上这个Token，服务端本身不在存储系统上存储相关信息(当然有定制需求的话也是需要的)，而是每次都计算当前Token是否有效，用时间换空间。
CAS两者都可以愉快的支持(基于JWT的可以参考看图理解JWT如何用于单点登录 - 流云诸葛 - 博客园，下文是用Cookie来举例说明的)，因为在CAS的Client里，也就是业务子系统里，几乎不对认证做任何事情，最多创建出一个局部的Session，认证的事情都交给了专门的CAS Server来处理。
第一次登陆
假设现在我们第一次打开基于ABC云的XYZ物联网应用。
这个时候跟认证有关的Cookie还是空的，物联网应用啥都不用管，直接让客户端重定向到云平台的CAS服务器的登陆页，当然在URL上要带上访问的页面地址，否则认证成功后转不回来了。
认证通过后，CAS会
- 建立一个session。
- 创建一个ticket，这个ticket相当于是SessionID，用于业务系统向CAS请求验证的标识
- 重定向回第一次访问的页面
重定向到业务系统
重定向过去后，业务系统发现请求中有ticket，它会拿了这个ticket去CAS那边验证，如果验证通过，那么它自己会建一个局部的会话，把Cookie发给浏览器，同时返回请求页面的内容，而之前CAS发给浏览器的Cookie在目前场景下没有什么用。
等到下一次访问该系统的另一个页面时，业务系统直接就可以验证它自己创建的局部会话了，不再需要到CAS服务器那边兜一圈。
访问另一个业务系统
如果要访问另一个业务系统，假设是ABC云平台的JKL客户关系管理系统，那么此时跟第一次登陆的上半部分一样，会重定向到CAS服务器系统的登陆页。
别忘了刚才CAS的一个Cookie还留在了我们浏览器那边，在重定向的时候会带上这个Cookie，这时CAS发现这个Cookie有效，已经认证过了，那么它就直接让浏览器重定向到JKL系统的页面去了，也带上了一个ticket。
接下来的事情就跟第二张图完全一样了。
总结
从Jasig CAS Web and Proxy flow盗了张图，按照数字顺序看下去就行了
