单点登陆(SSO)的个人理解

这两天折腾了一下单点登陆的Demo，大概明白了其中的原理，所以以下做一些记录，单点登陆也分两种，一种比较简单，一种就比较复杂一点，我们一一来说；

一、两个系统同顶级域名的情况

因为有同顶级域名，所以可以共享Cookie，所以这种环境下，有以下几个要点，搞懂了也就把这种模式搞懂了；
1、同顶级域名(a.dalomao.com和b.dalomao.com);
2、前端跨子域写入Cookie[“TicketId”]（TicketId的作用和我们一般情况下的ss-id一样，用来标识身份）;
3、后端的TicketId对应的身份信息写在一个中间键中，例如Redis中（因不同系统部署在不同服务器下，故不能用应用服务器的缓存）；
原理就是：子域1登陆 -> 服务1将Ticket对应的身份信息写在Redis中，并返回TicketId给子域1 -> 子域1将TicketId写到同顶级域名的子域2的Cookies中 -> 子域2请求时，服务2发现Cookies中已经有TicketId -> 从Redis获取TicketId的对应信息 -> 获取成功，子域2的请求标识为已登陆，如下流程图：
可以看出，其实就是利用共享Cookie和共享Session实现的，因为http请求本来就是无状态的，而是否登陆是通过Cookie和Session来判断的，当Cookie及Session都实现了共享后，那么单点登陆也就实现了；
**注销：**销毁对应的Cookie以及Redis的记录即可
注：这种方法只合适同顶级域名的两个系统，因为不同顶级域名的话，是无法共享Cookie的

2、两个系统完全独立的情况

这种环境下无法共享Cookie，所以情况会复杂一点，但是万变不离其宗，我们前面就说过http请求本身是没有状态的，故要判断你是否登陆，是要通过Cookie和Session这一类数据记录信息的，所以这种环境下同样也是，只不过实现的方式会比较复杂；同样先说几个要点
1、需要有3个或以上系统，单点登陆服务器（SSOServer），系统1(SSOClientOne)，系统2(SSOClientTwo);
2、前端带参用Get方式跳转，SSOClient需告诉SSOServer是谁请求他的，以提供SSOServer在登陆成功后跳转回来，在跳转回来的时候，还需要在参数中带上token；
3、SSOClient利用token在后台请求SSOServer来验证token是否有效；
注:SSOServer在登陆成功后为何不能直接返回登陆状态给SSOClient，而是返回一个 token给SSOClient再重新去验证？因两个系统间的跳转是在前端进行的，用户可以进行伪造，是不安全的，故只返回一个token，则SSOClient的后端再去确认token是否有效，以保证信息安全
具体流程图如下：

这个原理就是各客户网站(SSOClient)不在提供登陆，判断是否登陆是通过跳转到用户信息管理服务(OSSServer)去验证，OSSServer登陆过的，那就是登陆了，OSSServer没登陆过的，则是未登陆，需要进行登陆；
而OSSServer是一个独立的网站，Cookie和Session都是自己的，就不存在不能判断是否登陆的问题，So~以上问题就解决了
要点只不过是带参多次跳转而以；
注销：
1、用户向系统1发起注销请求
2、系统1(SSOClientOne)根据用户与系统1建立的会话id拿到token，向sso认证中心(SSOServer)发起注销请求
sso认证中心(SSOServer)校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址
3、sso认证中心向所有注册系统发起注销请求
4、各注册系统接收sso认证中心的注销请求，销毁局部会话
5、sso认证中心引导用户至登录页面

单点登陆到此就讲完了~