简介
单点登录Single Sign On简称SSO。在多个应用系统中，用户只需要登录一次就可以访问其他相互信任的应用系统
技术背景
多系统登录认证机制：
- 用户访问需要登录的应用；
- 应用检查session信息列表发现用户为登录，跳转到登录页；
- 用户填写登录信息，完成登录认证；
- 服务端生成唯一的sessionId保存在服务端设置过期时间，并返回登录凭证Token，存储在浏览器本地Cookie中；
- 用户下次再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户是否登录。如果不做特殊配置，这个Cookie的名字叫做jsessionid，值在服务端（server）是唯一的；
- 用户退出登录，服务端删除SessionId；
以上是JWT（JsonWebToken）的基本实现原理
同域名下的单点登录
一般企业只有一个一级域名，如 baidu.com，通过二级域名区分不同应用，如百度地图 map.baidu.com，百度网盘 pan.baidu.com，同时还会有一个登录系统，如 sign.baidu.com ，只包含登录功能。
- 用户访问需要登录的应用，如 pan.baidu.com，服务器发现用户没有登录，跳转到登录应用
- 用户填写登录信息，完成登录认证；
- 服务端生成SessionId，返回登录凭证Token，登录平台把Token写入Cookie，并修改Cookie的domain，设置成顶域，即 baidu.com。这样所有二级域名都可以访问这个顶域Cookie；
- 登录成功后重定向到用户想要访问的平台，如 pan.baidu.com，浏览器自动带上Cookie中的信息，服务端检测用户登录信息，认证登录状态
ps：不同的域名服务之间不能共享Session信息，服务端可以通过Spring-Session技术解决
不同域名下的单点登录
同域名下的单点登陆并不是真正意义上的单点登录，且所有二级域名共享Cookie存在安全隐患。下面介绍CAS（Central Authentication Service）实现不同域名下的单点登录。顾名思义，CAS是单独抽离出来的用户认证系统，包含CAS Client和CAS Server。
先丢出一张CAS工作流程图
SSO工作流程：
- 用户访问需要鉴权的资源，如 a.com；
- a.com 服务发现用户没有登录，302重定向到CAS Client；
- 用户填写登录信息发送请求到CAS Server，CAS Server校验登录信息，校验成功，CAS Server生成JeSessionId返回存储到浏览器Cookie，并生成ST票据（Service Ticket）作为参数重定向到 a.com；
- a.com拿到ST票据后向CAS Server发送请求验证ST票据的有效性，验证成功后把a.com登录状态写入session并设置a.com域下的Cookie；
- 用户再次访问a.com 是便可以带着Cookie中存储的a.com登录信息（JeSessionId）进行登录校验；
当用户访问其他相互信任的应用 b.com时：
- 用户访问 b.com，b.com服务发现用户未登录，302重定向到CAS Server；
- 此时CAS Server已经登录过，浏览器会自动带上包含登录信息的Cookie，用户不需要重新登陆CAS；
- CAS Server生成ST票据并重定向到 b.com；
- b.com向CAS Server发送请求验证ST票据的有效性，验证通过后把 b.com登录状态写入session并设置b.com域下的Cookie；
这样b.com就不用走登录流程了，自此就实现了“一处登录，处处访问”
ps：业务系统向CAS Server验证ST票据有效性的必要性，就像我们平时坐火车飞机一样，并不是乘客买一张票无需经过检票流程就可以乘车的，如果用户直接访问业务系统，并带上伪造的用户信息，业务系统是不是也认为用户登录成功呢，这样是很危险的
