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 到最初的那个请求