版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/CronousGT/article/details/82562237
主要是学习了这篇微博：https://www.cnblogs.com/EzrealLiu/p/5559255.html
这篇文章在方案3和方案4中讲解的个人有点不理解，加了一点自己的理解
原文
1.U第一次访问W，W验证失败，跳转至SSO要求U进行登录验证；
登录并使各不同Domain下：
2.U 给SSO发送登录请求，SSO验证成功，生成SessionID 并保存UserInfo；
返回给U的Response 将 UserInfo 存放至cookie中，Domain为SD；/*个人觉得这里可以将SessionID放入cookie也可以，之后在缓存中获取即可*/
3.将 2 中 cookie 内容作为query parameter 重定向至T，T验证后成功返回给U，也在Response 中设置 cookie；Domain为TD；
4.U自动访问SSO，SSO将请求重定向至W，完成U对W 的访问；
5.U 再访问 T，验证成功并允许U进行访问；这里我们要注意，方案三主要将UserInfo写入之后直接访问T的浏览器的缓存中，这时候U不用在经过SSO这一层了，因为cookie中已经有了UserInfo的信息。而在方案4中则相反。这点要非常注意，也是理解的关键。
下面看方案4，方案4是为了对方案三的所有回写的一个改进，每次访问才做回写，解决了方案3的卡顿问题
1.用户U访问W ，W进行验证，验证失败，跳转至SSO，要求U登录；
2.U通过SSO登录，SSO进行验证，成功并生成SessionID，随后将UserInfo（ SessionID、ID和口令）存储到公共缓存C 中，跳转至W（携带SessionID），并允许U访问W；U保存UserInfo （ SessionID ） 至 cookie；
3.U访问T，T 进行验证，失败跳转至SSO，SSO将触发U请求SSO将验证信息随请求一并发给SSO，经SSO验证成功跳转至Ｔ，允许U对T 的访问；使U保存UserInfo（ SessionID）至cookie；这里我们会发现，U在访问T的时候和方案3完全不同，方案3是直接访问T不用经过SSO层，这里需要经过SSO层？为什么呢？因为U在访问W的时候将SessionID写入了SSO层的cookie中，所以当我们U访问T时，我们将请求直接转到SSO层，利用SSO层的cookie实现系统的登陆。明白这一点很关键。