单点登录( Single Sign On ，简称 SSO），是目前比较流行的企业业务整合的解决方案之一，用于多个应用系统间，用户只需要登录一次就可以访问所有相互信任的应用系统。
前置介绍：
同源策略，限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互，要求协议，端口和主机都相同。
HTTP 用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是无状态协议，所以服务器单从网络连接上无从知道客户身份。
那要如何才能识别客户端呢？给每个客户端颁发一个通行证，每次访问时都要求带上通行证，这样服务器就可以根据通行证识别客户了。最常见的方案就是 Cookie。
Cookie 是客户端保存用户信息的一种机制，保存在客户机硬盘上。可以由服务器响应报文 Set-Cookie 的首部字段信息或者客户端 document.cookie来设置，并随着每次请求发送到服务器。子域名可以获取父级域名 Cookie。
Session 其实是一个抽象概念，用于跟踪会话，识别多次 HTTP 请求来自同一个客户端。
Cookie 只是通用性较好的一种实现方案，通常是设置一个名为 SessionID（名称可自定义，便于描述，本文均使用此名称）的 Cookie，每次请求时携带该 Cookie，后台服务即可依赖此 SessionID 值识别客户端。
单系统登录
在介绍单点登录之前，我们先来了解一下在浏览器中，访问一个需要登录的应用时主要发生的一系列流程，如下图所示：
数据库存储关联：将 SessionID 与数据信息关联，存储在 Redis、MySQL 等数据库中。
数据加密直接存储：比如 JWT 方式，用户数据直接从 SessionID 值解密出来（此方式时 Cookie 名称以 Token 居多）。
多系统登录问题
同域名
不同子域名
完全不同域名
前端跨域带 Cookie
如果只是期望异步请求时获取当前用户的登录态，可以通过发送跨域请求到已经登录过的域名，并配置属性：
xhrFields: {
withCredentials: true
}
CAS
页面访问流程如下图：
所有的登录过程都依赖于 CAS 服务，包含用户登录页面、ST 生成、验证。
为了保证 ST 的安全性，一般 ST 都是随机生成的，没有规律性。
CAS 规定 ST 只能保留一定的时间，之后 CAS 服务会让它失效，而且，CAS 协议规定 ST 只能使用一次，无论 ST 验证是否成功，CAS 服务都会清除服务端缓存中的该 ST，从而规避同一个 ST 被使用两次或被窃取的风险。
作者：余诺
编辑：陶家龙、孙淑娟
出处：转载自公众号政采云前端团队
精彩文章推荐：
