数仓沉思录（八）SSO的简单版

学习需要积极反馈才能做到有效监控，学习的过程是一个需要付出努力且不断试错的过程，善于调整学习动机，做好情绪管理，始终将关注点放在精通专业技能这一角度上，精益求精便指日可待。

题外话：终于买了一部新的thinkpad t480s本子，上一个t430跟了我5年多，终于可以退居二线，专用于影音娱乐码字用了！没有入坑MAC，总认为货不等值，再则Linux要比MacOS熟悉多了，不想再浪费时间，Linux上码代码同样非常爽。那些拿着Mac装着Windows的，这分明是赤裸裸地炫富嘛……

回正题：SSO英文全称（Single Sign On)，中文单点登陆，优点自不必啰嗦，网上一堆相关描述，其中有几点很值得一提，一是提升用户体验，用户不用记忆那么多用户名和密码了，省心了很多；二是提升开发体验，一个大而复杂的系统可以拆成更小更细的子系统去完成，为落实系统模块化扫除障碍；三是如今采用REST架构的系统很多，系统部署在多个节点会遇到一个跨域的问题，有了SSO，可以很优雅的解决跨域的问题。

本文设计的SSO的功能包含有用户注册、修改密码、修改用户信息、信息查询等等常规用户管理模块应该有的功能，这些是次要的，主要看该怎么与其他系统交互！

设计图如下所示：

这里以用户访问受保护页面为例，交互流程描述如下：

1、用户通过浏览器访问子系统A

2、子系统A检查用户请求，是否有权限访问指定页面（这里举例为是否已登陆）

3、如果有，则返回指定页面，如果没有则向SSO服务器发起一个用户标识申请（UUID）

4、SSO服务器返回一个UUID给子系统A

5、子系统A协助SSO服务将UUID写入客户端COOKIE，并指定回调地址（指向SSO登陆地址）

6、用户浏览器访问指定的回调地址，执行登陆流程

7、SSO服务器将用户UUID与新产生的SESSION绑定，SESSION信息包含如超时时间，UUID等，SESSION信息保存在一个共享的缓存区中，通常是类似于Redis这样的集群中，所有子系统均可访问和更新，个人倾向于使用分布式KV且有用户概念，支持事务的系统中。

8、返回登陆结果信息

9、如果登陆成功，则继续访问指定的受保护页面

10、子系统A，根据用户提交的信息，这里主要是UUID，向SSO请求其他用户信息如角色、权限等

11、SSO服务器返回子系统A所需要的用户信息（每个系统所需的用户信息是不一样的）

12、子系统A返回指定页面，下面该干嘛就干嘛了

整个交互流程到此结束，当然后面还有超时退出和用户主动退出系统的操作，这个就不是关键问题了。该用户使用同一台设备登陆其他子系统，携带COOKIE中信息去访问就可以了，如果换了终端，当然必须得重新登陆了。

这样设计简单吧，而且SSO服务器的压力很小，数据与应用是分离的，SSO服务可以部N个实例都没有问题，所有子系统部署实例数也不会受限制，所有的压力都在分布式缓存上了。当然，这样的设计在公司内部受限的场景中使用是没有问题的，要用到公网上，还有安全问题是需要考虑的，比如缓存中的数据第一要防止被篡改，第二防止信息泄漏，像Redis这种处于安全性考量，是不能用于session缓存的，要用也要极其小心！

最后，要表示一下歉意的，每篇文章之后一般会提一下下一篇会写些什么，但因为工作内容会不断变化，导致有些承诺不能及时兑现，实在抱歉，所以从此篇开始不再提下篇的相关主题内容了