一、单点登录含义
单点登录（简称SSO），指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的系统。简而言之，多个系统，统一登陆。
为什么需要做单点登录系统呢？在一些互联网公司中，公司旗下可能会有多个子系统，每个登陆实现统一管理，多个账户信息统一管理 SSO单点登陆认证授权系统。比如阿里系的淘宝和天猫，显而易见这是两个系统，但是在使用过程中，只要你登录了淘宝，同时也意味着登录了天猫，如果每个子系统都需要登录认证，用户早就疯了，所以我们要解决的问题就是，用户只需要登录一次就可以访问所有相互信任的应用系统。
二、单点登录原理
sso需要一个独立的认证中心，所有子系统都通过认证中心的登录入口进行登录，登录时带上自己的地址，子系统只接受认证中心的授权，授权通过令牌（token）实现，sso认证中心验证用户的用户名密码正确，创建全局会话和token，token作为参数发送给各个子系统，子系统拿到token，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。
三、单点登录实现方式
单点登录的实现方案，一般就包含：Cookies，Session同步，分布式Session，目前的网站采用比较多的方式是token令牌和分布式Session的方式。
Cookies：一种保存在电脑上的一种文件，当我们使用电脑进行浏览网页的时候，服务器就会生成一个证书，并且返回给我们的电脑，这个证书就是cookie，一般情况下，cookie是服务器写入客户端的文件，我们也可以叫浏览器缓存。
Cookies的作用：一般情况下，网站是通过cookie对请求进行保存，会根据有用户进行特定的内容进行展示，也可以对密码进行存储，Cookie文件是以浏览器为载体，并且有浏览器为支撑，我们可以在浏览器中设置阻止，这样的话，服务器就不能写进Cookie，现在很多浏览器都是能支持Cookie，有时候，网站访问的时候，必须支持Cookie，不然会出现浏览器不能访问。
Cookies工作原理：我们访问网站的时候，首先向服务器发送一个请求，服务器会根据浏览器的编号，去生成一个cookie返回给用户，用户在下次访问的时候，就会把本地的cookie文件加上url一起发送给服务器，服务器以此来判断用户的状态。
Session：Session是指会话控制，是保存在服务器上一种机制，当客户端访问服务器的时候，服务器会把信息以某种形式记录在服务器上，恰恰和Cookie相反。
Session工作原理：
- 用户第一次请求服务器时，服务器端会生成一个sessionid
- 服务器端将生成的sessionid返回给客户端，通过set-cookie
- 客户端收到sessionid会将它保存在cookie中，当客户端再次访问服务端时会带上这个sessionid
- 当服务端再次接收到来自客户端的请求时，会先去检查是否存在sessionid，不存在就新建一个sessionid重复1,2的流程，如果存在就去遍历服务端的session文件，找到与这个sessionid相对应的文件，文件中的键值便是sessionid，值为当前用户的一些信息
- 此后的请求都会交换这个 Session ID，进行有状态的会话。
1、Cookies实现方式
1.1、实现方式一：父域 Cookie
Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名 / IP 地址，在 Tomcat 中，domain 属性默认为当前域的域名 / IP 地址。path 属性的有效值是以 “/” 开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。
如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的 Cookie。
利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。
总结：此种实现方式比较简单，但不支持跨主域名。
1.2、实现方式二：认证中心
我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。
用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）
应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。
应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。
这里顺便介绍两款认证中心的开源实现：
- Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了 Apereo 基金会，项目也随之更名为 Apereo CAS。
- XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。
总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。
2、Session实现方式
2.1、实现方式三：LocalStorage 跨域
前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。
在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。
关键代码如下：
// 获取 token var token = result.data.token; // 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML var iframe = document.createElement("iframe"); iframe.src = "http://app1.com/localstorage.html"; document.body.append(iframe); // 使用postMessage()方法将token传递给iframe setTimeout(function () { iframe.contentWindow.postMessage(token, "http://app1.com"); }, 4000); setTimeout(function () { iframe.remove(); }, 6000); // 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage window.addEventListener('message', function (event) { localStorage.setItem('token', event.data) }, false);
前端通过 iframe+postMessage () 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。
总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。
2.1、分布式session方式实现单点登录
流程运行：
（1） 用户第一次登录时，将会话信息（用户Id和用户信息），比如以用户Id为Key，写入分布式Session；
（2） 用户再次登录时，获取分布式Session，是否有会话信息，如果没有则调到登录页；
（3） 一般采用Cache中间件实现，建议使用Redis，因此它有持久化功能，方便分布式Session宕机后，可以从持久化存储中加载会话信息；
（4） 存入会话时，可以设置会话保持的时间，比如15分钟，超过后自动超时；
结合Cache中间件，实现的分布式Session，可以很好的模拟Session会话。
3、CAS中央认证服务
CAS是中央认证服务，一种独立开放指令协议。CAS 是 耶鲁大学（Yale University）发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。
