SingleSignOn（简称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下设置一个名为SessionID的cookie.com域名。当用户稍后访问news.demo.com时，后台服务也可以获取到SessionID来识别用户。完全不同的域名默认情况下，不同的域名不能直接共享cookie。如果前端跨域cookie只是希望在异步请求时获取当前用户的登录状态，可以向已经登录的域名发送跨域请求，配置属性：xhrFields:{withCredentials:true}这样可以在请求Cookie中携带目标域名，目标域名的服务可以识别当前用户。不过这需要目标域名的接口支持CORS访问（出于安全考虑，当CORS开启withCredentials时，浏览器不支持使用通配符*，需要明确设置可以访问的域名列表）跨域访问）。题外话：如果只是为了规避浏览器限制，达到通配符*一样的效果，达到让所有域名都可以访问的目的，请求源域名可以根据访问的Referrer解析为一个可访问的列表。但出于安全考虑，不建议使用，请设置清晰易访问的域名。CASCAS（CentralAuthenticationService），中央认证服务，是耶鲁大学发起的一个开源项目，旨在为Web应用系统提供可靠的单点登录方式。既然无法跨域获取，那么CAS如何共享呢？它通过跳转到中间域名来实现登录。页面访问流程如下图所示：下面是漫画形式，希望能让读者更好的理解：需要注意以下两点：所有登录过程都依赖于CAS服务，包括用户登录页面、ST生成、验证。为了保证ST的安全性，一般ST都是随机生成的，没有规律性。CAS规定ST只能保存一定的时间，之后CAS服务会使其失效。而且CAS协议规定ST只能使用一次。无论ST验证是否成功，CAS服务都会清除服务器缓存中的ST，从而避免出现相同的ST。一个ST被使用两次或被盗的风险。
