关于SSO一直没有深入的研究，在工作中也是对接的公司平台的SSO，最近频繁的与SSO打交道之后，我决定深入的理解一下它的实现原理；
一.SSO的实现种类
SSO系统在公司一般是独立部署的一套系统，需要各业务系统接入，回想一下之前传统系统都是业务+登录一体化，那个时候，我们可以将用户信息保存到session，那如果是微服务+独立SSO该怎么实现各系统session共享的问题?
1.基于共享session
我们都知道每台服务的session是互相不共享的，假设将我们的 商品服务、订单服务等服务的session都共享，就可以实现一处登录，全站访问的特点；
实现共享session的方式不是本文的重点，它存在一定的缺陷，就是所有的服务器都必须保持一致，不能说有些服务是tomcat，有些是jetty；
提升一种思路就是通过 Spring Session 或者 tomcat-redis-session-manager
2.基于认证中心
这种方案需要自己实现一套SSO或使用第三方的，所有系统的认证操作都是在这个系统中完成的，它管理着整个用户的状态，这种实现方式需要SSO系统提供有登录、注册等操作的前端页面。下面重点介绍下实现方式；
二.实现方式
我们模拟三个服务：
系统A：a.demo.com
系统B：b.demo.com
SSO：sso.demo.com
1.登录流程
关键点：
1.它用到了两个cookie(sid与token)和三次重定向；
2.token是写到a.demo.com域名下的，sid是写到sso.demo.com域名下的；
3.在验证token的时候，如何知道当前用户已经创建了全局会话？因为jwt的payload里面存储了之前创建sso的会话sid，所以当cas拿到jwt，就相当于知道了sid；
注意：
SSO服务如果是集群部署的，则需要解决sid共享问题；
2.访问系统B的页面
在这个过程中关键在于第一次重定向的时候，它会把sso.demo.com这个域名下的sid带给sso服务；
3.退出
最重要的是要清除sid的cookie，jwt的cookie可能业务系统都有创建，所以不可能在退出的时候还挨个去清除，只要sid一清除，那么即使那些jwt的cookie在下次访问的时候还会被传递到业务系统有服务端；
三.总结
在真实的项目中，可能需要考虑到更多的安全性的要求，比如：
1.使用https
2.http-only
3.CSRF
总的来说，优缺点主要有：
1.能够支持跨平台，跨语言实现单点登录；
2.重写向次数过多；
3.每次请求都需要调用SSO验证token有效性；