单点登录的三种实现方式
前言
在B/S系统中，登录功能通常都是基于Cookie来实现的。当用户登录成功后，一般会将登录状态记录到Session中，或者是给用户签发一个Token，无论哪一种方式，都需要在客户端保存一些信息（SessionID或Token），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用Cookie无疑是最方便的，因此我们一般都会将Session的ID或Token保存到Cookie中，当服务端收到请求后，通过验证Cookie中的信息来判断用户是否登录。
单点登录（SingleSignOn,SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，百度贴吧和百度地图是百度公司旗下的两个不同的应用系统，如果用户在百度贴吧登录过之后，当他访问百度地图时无需再次登录，那么就说明百度贴吧和百度地图之间实现了单点登录。
单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在Session中的，要实现共享登录状态，就要先共享Session，比如可以将Session序列化到Redis中，让多个应用系统共享同一个Redis，直接读取Redis来获取Session。当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管Session共享了，但是由于SessionID是往往保存在浏览器Cookie中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在app1.com中登录后，SessionID仅在浏览器访问app1.com时才会自动在请求头中携带，而当浏览器访问app2.com时，SessionID是不会被带过去的。实现单点登录的关键在于，如何让SessionID（或Token）在多个域中共享。
实现方式一：父域Cookie
在将具体实现之前，我们先来聊一聊Cookie的作用域。
Cookie的作用域由domain属性和path属性共同决定。domain属性的有效值为当前域或其父域的域名/IP地址，在Tomcat中，domain属性默认为当前域的域名/IP地址。path属性的有效值是以“/”开头的路径，在Tomcat中，path属性默认为当前Web应用的上下文路径。
如果将Cookie的domain属性设置为当前域的父域，那么就认为它是父域Cookie。Cookie有一个特点，即父域中的Cookie被子域所共享，换言之，子域会自动继承父域中的Cookie。
利用Cookie的这个特点，不难想到，将SessionID（或Token）保存到父域中不就行了。没错，我们只需要将Cookie的domain属性设置为父域的域名（主域名），同时将Cookie的path属性设置为根路径，这样所有的子域应用就都可以访问到这个Cookie了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如tieba.baidu.com和map.baidu.com，它们都建立在baidu.com这个主域名之下，那么它们就可以通过这种方式来实现单点登录。
总结：此种实现方式比较简单，但不支持跨主域名。
实现方式二：认证中心
我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的Web服务。
用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将Token写入Cookie。（注意这个Cookie是认证中心的，应用系统是访问不到的。）
应用系统检查当前请求有没有Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的Cookie自动带过去，因此，认证中心能够根据Cookie知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标URL，并在跳转前生成一个Token，拼接在目标URL的后面，回传给目标应用系统。
应用系统拿到Token之后，还需要向认证中心确认下Token的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将Token写入Cookie，然后给本次访问放行。（注意这个Cookie是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个Token，应用系统验证Token发现用户已登录，于是就不会有认证中心什么事了。
这里顺便介绍两款认证中心的开源实现：
- ApereoCAS是一个企业级单点登录系统，其中CAS的意思是”CentralAuthenticationService“。它最初是耶鲁大学实验室的项目，后来转让给了JASIG组织，项目更名为JASIGCAS，后来该组织并入了Apereo基金会，项目也随之更名为ApereoCAS。
- XXL-SSO是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。
总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。
实现方式三：LocalStorage跨域
前面，我们说实现单点登录的关键在于，如何让SessionID（或Token）在多个域中共享。
父域Cookie确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让Cookie跨域传递呢？
很遗憾，浏览器对Cookie的跨域限制越来越严格。Chrome浏览器还给Cookie新增了一个SameSite属性，此举几乎禁止了一切跨域请求的Cookie传递（超链接除外），并且只有当使用HTTPs协议时，才有可能被允许在AJAX跨域请求中接受服务器传来的Cookie。
不过，在前后端分离的情况下，完全可以不使用Cookie，我们可以选择将SessionID（或Token）保存到浏览器的LocalStorage中，让前端在每次向后端发送请求时，主动将LocalStorage的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将SessionID（或Token）放在响应体中传递给前端。
在这样的场景下，单点登录完全可以在前端实现。前端拿到SessionID（或Token）后，除了将它写入自己的LocalStorage中之外，还可以通过特殊手段将它写入多个其他域下的LocalStorage中。
关键代码如下：
//获取token
vartoken=result.data.token;
//动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
variframe=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被多个域所共享。
总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。
补充：域名分级
从专业的角度来说（根据《计算机网络》中的定义），.com、.cn为一级域名（也称顶级域名），.com.cn、baidu.com为二级域名，sina.com.cn、tieba.baidu.com为三级域名，以此类推，N级域名就是N-1级域名的直接子域名。
从使用者的角度来说，一般把可支持独立备案的主域名称作一级域名，如baidu.com、sina.com.cn皆可称作一级域名，在主域名下建立的直接子域名称作二级域名，如tieba.baidu.com为二级域名。
为了避免歧义，本人将使用“主域名“替代”一级域名“的说法。
以上就是单点登录的三种实现方式的详细内容，更多关于单点登录实现的资料请关注毛票票其它相关文章！