传统的登录模式
每一个系统都做一套登录功能，登录了A系统之后，如果想要使用B系统，那么需要再登录一次，即使两个系统的账号是一致的。
假设一个企业有A B两个系统，那么用户登录这两个系统需要两个cookie来保存两个系统的登录信息。
image
这样做的好处是开发方便，在单机的情况下直接使用session和cookie即可完成一个这样的登录设计。缺点就是用户使用不同的系统，需要多次登录，体验不够好。
改进版本——同域下的单点登录的设计
一般来说，同一个企业的系统所采用的一级域名是都是相同的，比如a.xxx.com，b.xxx.com。我们可以在登录的时候把cookie设置为一级域名级别，即xxx.com。这样子的话a.xxx.com和b.xxx.com两个系统都可以访问到同一个cookie信息，那么在后端实现了session共享的情况下，即可实现一个系统登录，可以让另外一个系统免登陆。
实现session共享可以参考之前的文章：SpringBoot+Redis实现session共享
image
当然这种方案并不好，因为往往很多系统一级域名都是不相同的，比如某宝和某猫。
改进方案——单点登录系统
同域下的单点登录可以简单利用Cookie和session来解决，但是很多时候系统之间是不同一级域名的。不同域之间Cookie是不共享的，怎么办？这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。
先来看一个CAS的流程图：
image
相信这个图看起来很费经，其实CAS流程并不复杂：
1、用户访问A系统，A系统需要登录，检测到用户没有进行登录，那么就重定向用户到CAS系统。
2、用户到了CAS系统之后，发现用户也没在CAS上的登录过，那么则跳转到登录界面。
3、用户登录CAS系统后，将登录状态写入CAS的session中，浏览器中写入CAS域下的cookie。
4、CAS系统登录完成后会给用户生成一个Service Ticket（ST），此时CAS系统会把用户重定向到系统A上，把ST发送给A系统。
5、A系统接收到ST之后，会去CAS服务上进行验证是否有效。
6、验证通过后把用户的登录状态写入A系统的session，并且在A的域下写入cookie。
经过上面的步骤，用户已经在A系统完成了登录。
如果此时用户继续访问系统B，那么流程如下：
1、用户访问B系统，没有登录，则跳转到CAS系统。
2、CAS系统检测到用户登录成功了，不需要用户再次登录，直接生成ST，把用户重定向回B系统，把ST发送给B系统。
3、B系统接收到ST之后，会去CAS服务上进行验证是否有效。
4、验证通过后把用户的登录状态写入B系统的session，并且在B的域下写入cookie。
此时已经完成了B系统的验证过程。
总结
单点登录（SSO）的流程基本就是这样，原理相信大家都能够理解。所谓的单点登录，就是让用户在一个地方（CAS）统一进行登录，然后各个业务系统接入CAS完成用户登录状态的管理。这里只是做个简单介绍，后续会写写demo来真正实现单点登录功能。
网友评论