单点登录( Single Sign On ，简称 SSO)，是目前比较流行的企业业务整合的解决方案之一，用于多个应用系统间，用户只需要登录一次就可以访问所有相互信任的应用系统。
图片来自 Pexels
前置介绍：
- 同源策略，限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互，要求协议，端口和主机都相同。
- HTTP 用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是无状态协议，所以服务器单从网络连接上无从知道客户身份。
- 那要如何才能识别客户端呢?给每个客户端颁发一个通行证，每次访问时都要求带上通行证，这样服务器就可以根据通行证识别客户了。最常见的方案就是 Cookie。
- Cookie 是客户端保存用户信息的一种机制，保存在客户机硬盘上。可以由服务器响应报文 Set-Cookie 的首部字段信息或者客户端 document.cookie来设置，并随着每次请求发送到服务器。子域名可以获取父级域名 Cookie。
- Session 其实是一个抽象概念，用于跟踪会话，识别多次 HTTP 请求来自同一个客户端。
- Cookie 只是通用性较好的一种实现方案，通常是设置一个名为 SessionID(名称可自定义，便于描述，本文均使用此名称)的 Cookie，每次请求时携带该 Cookie，后台服务即可依赖此 SessionID 值识别客户端。
单系统登录
在介绍单点登录之前，我们先来了解一下在浏览器中，访问一个需要登录的应用时主要发生的一系列流程，如下图所示：
以下为连环画形式，期望能让读者更好的理解：
依赖于登录后设置的 Cookie，之后每次访问时都会携带该 Cookie，从而让后台服务能识别当前登录用户。
题外话：后台是如何通过 SessionID 知道是哪个用户呢?
- 数据库存储关联：将 SessionID 与数据信息关联，存储在 Redis、MySQL 等数据库中。
- 数据加密直接存储：比如 JWT 方式，用户数据直接从 SessionID 值解密出来(此方式时 Cookie 名称以 Token 居多)。
多系统登录问题
同域名
当访问同域名下的页面时，Cookie 和单系统登录时一样，会正常携带，后台服务即可直接获取到对应的 SessionID 值，后台为单服务还是多服务无差别。
不同子域名
子域名间 Cookie 是不共享的，但各子域名均可获取到父级域名的 Cookie，即 app.demo.com与 news.demo.com均可以获取 demo.com域名下的 Cookie。
所以可以通过将 Cookie 设置在父级域名上，可以达到子域名共享的效果，即当用户在 app.demo.com 域名下登录时，在demo.com域名下设置名为 SessionID 的 Cookie。
当用户之后访问news.demo.com时，后台服务也可以获取到该 SessionID，从而识别用户。
完全不同域名
默认情况下，不同域名是无法直接共享 Cookie 的。
前端跨域带 Cookie
如果只是期望异步请求时获取当前用户的登录态，可以通过发送跨域请求到已经登录过的域名，并配置属性：
- xhrFields: {
- withCredentials: true
- }
这样可在请求时携带目标域名的 Cookie，目标域名的服务即可识别当前用户。
但是，这要求目标域名的接口支持 CORS 访问(出于安全考虑，CORS 开启 withCredentials 时，浏览器不支持使用通配符*，需明确设置可跨域访问的域名名单)。
题外话：如果只是为了规避浏览器的限制，实现与通配*同样的效果，到达所有域名都可以访问的目的，可根据访问的 Referrer 解析请求来源域名，作为可访问名单。但是出于安全考虑，不推荐使用，请设置明确的可访问域名。
CAS
CAS(Central Authentication Service)，即中央认证服务，是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法。
既然不能跨域获取，那 CAS 如何做到共享呢?它通过跳转中间域名的方式来实现登录。
页面访问流程如下图：
以下为连环画形式，期望能让读者更好的理解：
其中需要关注以下 2 点：
- 所有的登录过程都依赖于 CAS 服务，包含用户登录页面、ST 生成、验证。
- 为了保证 ST 的安全性，一般 ST 都是随机生成的，没有规律性。
- CAS 规定 ST 只能保留一定的时间，之后 CAS 服务会让它失效，而且，CAS 协议规定 ST 只能使用一次，无论 ST 验证是否成功，CAS 服务都会清除服务端缓存中的该 ST，从而规避同一个 ST 被使用两次或被窃取的风险。
