多系统的两种单点登录（sso）的方式

何时需要引入单点登录：

前提：明白 一次cs请求与响应的过程，就是在服务器创建一个session，并且返回一个cookie （访问tomcat时，cookie通常是JSESSIONID）给到客户端浏览器，然后浏览器再次的请求，会携带此cookie，经过session的验证之后，就可以在同一个session中继续进行该会话了。

但是对于一个分布式的项目来说，一个整体的系统是由多个子系统来实现的，甚至这些子系统可能来自于不同的技术栈实现的。

这时候的系统其实对于用户来说，就是一个统一的整体，所以要求用户在完成一次登录之后，访问所有系统的子系统，只要登录/注销一次就够了。

这个时候采用单系统的登录方式已经无法满足了，因为不同的系统的域名不同，所以完成一次登录之后，cookie无法随着不同的域名，完成对服务器的请求。

那么根据上述的问题，cookie无法跟随不同的域名发出请求，有了第一个解决方案。

设置主域名：

这里需要给到一个理论就是，被服务器返回的响应中携带并保存在浏览器的的cookie，当继续发出请求时，默认只能由同一个域名发出请求时，才能携带。

但是这里可以给cookie 设置一个主域名，如上图所示，就是说，有主域名或者子域名获得了cookie之后，在设置了cookie主域名的前提下，其他的主域名是主域名的子域名，可以在请求当中一并携带着发出。

如主域名为 zhangsan.com
子域名为 a.zhangsan,com 、b.zhangsan.com 、c.c.zhangsan.com
这些子域名都是可以在请求时携带cookie的。

拦路虎：首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是web服务器）要相同，不然cookie的key值（tomcat为JSESSIONID）不同，无法维持会话，共享cookie的方式是无法实现跨语言技术平台登录的，比如java、php、.net系统之间；第三，cookie本身不安全。
于是推出第二个方案

第二种方案 是常见的代码中自己实现sso 单点登录：

sso独立的认证中心：

如上图所示：
1、当客户端首次访问第一个系统a的时候，系统a由于没有该用户的session，会跳转到sso认证中心。
2、sso认证中心发现 并没有该用户的session，则会返回给用户一个登录页面。
3、用户发出登录请求之后，sso会设置该session，并且会返回cookie给到用户。
（上述步骤就是用户在sso完成登录，并且创建会话的过程。）
4、此时sso会返回给系统a一个ticket。
5、系统a 会携带该ticket 到 sso，sso会验证此ticket是否有效，有效还会返回用户信息。
6、系统a获得用户信息之后，会新建一个session并且将用户信息保存到session，并且返回给用户一个cookie。
7、用户再次访问系统a 就可以用系统a给到的cookie来发出请求。

上图是当用户访问第二个系统，系统b的时候的流程
1、当用户访问系统b时，会把sso给到的cookie携带着来发出请求。
2、系统b发现没有匹配的session，就会携带着sso给到用户的cookie，请求sso认证中心。
3、认证中心发现该cookie是能够匹配session的，那么就会直接给系统b一个ticket。
4、此时的流程跟上面的流程同理。
系统b 会携带该ticket 到 sso，sso会验证此ticket是否有效，有效还会返回用户信息。
5、系统b获得用户信息之后，会新建一个session并且将用户信息保存到session，并且返回给用户一个cookie。
6、用户再次访问系统b 就可以用系统b给到的cookie来发出请求。

sso独立的认证中心的纠正：

上述的解释 在理解上可能存在一些问题，是我在B站上面看到的一个视频讲解，但是他讲的只对了一半，
客户端第一次登录a系统时，a系统把身份验证，转发给认证系统，认证系统提供给他页面完成登录，并且把 令牌交给客户端，客户端下次再来登录任何系统 都会携带该令牌，并到认证系统中验证真伪。
，然后上面的部分也不删除，作为错误对照，下面内容给出正确解释。