一、前言本文在简要介绍了SSO的概念和原理后，用SpringBoot Redis实现了一个简单的SSO系统。 系统使用ticket的形式，cookie携带ticket向sso服务器进行认证，认证成功后允许访问请求地址。
物料地址：物料地址
二、SSO介绍SSO (单一信号)。 单点登录，简单地说，是在具有多个子系统系统中，仅登录一个子系统，然后在访问其他子系统时，不需要再次登录，即"一次登录、多个访问"
单点登录的大致流程如下(基于cookie )。
1 .如果用户首次接入a系统，a系统发现用户没有登录，则重定向至SSO认证中心，携带请求url并进行登录认证；
2 .用户在SSO认证中心进行用户名和密码认证登录，登录成功后，服务器生成ticket，重定向至系统a的源url，并将该ticket添加到url参数中。
3 .系统a获取url参数中的ticket，向SSO开始ticket的比较检查，如果比较检查成功，系统a释放，将ticket保存在cookie中。
4 .用户进入b系统，此时在b系统的域名下已经携带了ticket，直接开始对SSO进行ticket的比较检测，如果比较检测成功，释放后将ticket保存到cookie中(cookie )
5 .用户注销时，删除domain下的cookie。
流程图大致如下。
三.基于SpringBoot和Redis实现系统结构
实现原理很简单，使用共享cookie实现SSO。 sso-server使用redis存储用户ticket，app-a和app-b使用Spring拦截器过滤用户请求。 每个请求都必须在SO-server上验证ticket，如果验证失败，则必须重定向到登录“带有源url”
系统以使用一次性ticket为特点，一个ticket只能使用一次，使用后立即失效，保证ticket的安全性。
主要代码请参阅项目源代码： https://gitee.com/xgpxg/SSO-DEMO
四.问题与思考使用cookie还是url？ 关于ticket的传输，我曾为是使用cookie还是使用url的附加参数而烦恼，但最终还是很容易想到，还是使用cookie。
如何保证ticket的安全性？ 这个问题也让我烦恼的下午，我想要一种完美而安全的ticket发布形式。 最后发现，网络没有绝对的安全，当解密它带来的利益小于解密后的利益时，他是安全的。 也就是说安全是相对的。 因此，ticket作为cookie或url参数传递，原本就没有安全性。 我们可以保证的是，如何比较ticket，如何验证得到同一ticket的用户是同一用户。 针对这个问题，我使用的是一次性ticket。 如上所述，这样虽然不能保证绝对的安全，但是可以在一定程度上有效地防止他人直接监听cookie获得权限。
3 .关于cookie的域名在测试中发现cookie写入的是辅助域名，如aa.test.com而不是test.com，导致其他系统无法共享cookie，导致单点登录失败。 解决方案是将domain直接设定为. test.com即可。 注意前面的点不能省略。其次，在yml中直接使用按以下结构设定cookie的域是无效的
server : servlet : session 3360 cookie : domain 3360.test.com4.注销时是直接请求sso-server还是请求子系统？ 考虑到是子系统间共享的cookie，清除子系统的cookie即可。
五.用于单点登录和单点登录演示的域名：
#支持的app-a、端口支持8081127.0.0.1 aa.test.com#的app-b、端口支持8082127.0.0.1 aa.test.com#的sso-server、端口
2 .然后，进入app-a的主页(http://aa.test.com/home )，由于没有登录，跳转到sso的登录页面；
3 .登录成功后，自动返回app-a的home界面。 此时，如果再次进入app-b的home界面，则不需要再次登录
如果您在app-b的Home界面上退出登录，然后进入app-a的Home界面，则会提示您重新登录