SSO
SSO（Single Sign On）即单点登录。把两个及以上的产品中的用户登录逻辑抽离出来，达到只需要登录一次就可以访问不同的产品的功能。这样可以带来很多的好处，比如避免重复开发，提升用户体验...
CAS
SSO 只是一种架构，而 CAS 则是这种架构的一种具体实现。CAS（Central Authentication Service）中心授权服务，是一种开源协议，分为1.0和2.0版本。1.0 是基础模式，2.0 为代理模式，适用与非 web 应用的SSO，1.0 适用于 web 应用。
CAS 1.0 相关概念
术语
- Client：用户
- Server：中心服务器，即 SSO 中负责登录的 service
- Service：需要 SSO 的各个服务，对应的是不同的业务 service
票据
TGT：Ticket Granting Ticket
TGT 是CAS 为用户签发的登录 ticket，也是用于验证用户登录成功的唯一方式。 TGT 封装了 Cookie 值以及 Cookie 值对应的用户信息，CAS 通过 Cookie 值（TGC）为 key 查询缓存中有无 TGT（TGC:TGT（key:value）），如果有的话就说明用户已经登录成。
TGC：Ticket Granting Cookie
CAS 会将生成的 TGT 放在 session 中，而 TGC 就是这个 session 的唯一标识(sessionId)，可以认为是 TGT 的key，为 TGT 就是 TGC 的 value，TGC 以 cookie 的形式保存在浏览器中，每个请求都会尝试携带 TGC。（每个服务都会在 session 和 cookie 中保存对应的 TGT 和 TGC）
ST：Service Ticket
ST 是当用户访问某一服务时提供的 ticket。用户在访问其他服务时，发现没有 cookie 或 ST ，那么就会302到 CAS 服务器获取 ST。然后会携带着 ST 302 回来。
借助官网的 Sequence Diagram 来看看整个流程：
- 当用户未登录情况下访问非 CAS 服务（service-1）时，CAS 会进行拦截发现当前账号未认证（没有携带JSESSIONID或者ST），于是 302 到 CAS 服务器
- CAS 服务器会 check 浏览器是否有 TGC ，发现没有，说明用户真的没有登录过，于是302到登录叶敏啊
- 用户提交登录信息到 CAS 服务器，认证成功
- 认证成功后，CAS 会保存一个 session，在浏览器保存一个 CASTGC cookie，然后302到最初访问的那个URL，URL上会携带一个 ST 参数
- 请求抵达该该服务（service-1）时，发现有 ST 参数，那么会 302 到 CAS 服务器验证 ST 是否有效
- 如果有效那么该服务（service-1）就会在（service-1）中生成该服务对应的 session，然后返回浏览器，生成 JSESSIONID cookie，并携带 JESSIONID cookie 302 到最初的那个请求