SSO单点登陆，典型应用场景逻辑走向分析

我们相信：世界是美好的，你是我也是。平行空间的世界里面，不同版本的生活也在继续...

本文中，苏南大叔从宏观角度上分析一下legalthings/sso的逻辑走向，并不会涉及太具体的代码，仅仅从逻辑原理层面上进行代码分析。在后续的代码中，会对具体的业务代码实现细节进行详细分析。

本文的范例来自legalthings/sso。截至到发稿，最新版本为0.3.0 - Bearer auth。

基本概念

本文共涉及以下几个基本概念：

• 角色：用户浏览器，网站broker，鉴权服务器sso server
• 鉴权：用户cookie、网站和用户之间的token(也就是上述cookie)、网站和鉴权服务器之间的checksum。

访问第一个broker

用户浏览器

用户通过浏览器访问网站broker，broker初始化sso server相关设置。用户第一次访问，不存在cookie，所以broker将用户浏览器使用307状态码导向到sso server，进行attach操作。

attach操作中，broker随机生成了token，当然也就是用户的cookie，然后将用户浏览器导向到了sso server的特定attach链接中，这个链接url使用了broker和sso server之间的鉴权checksum（token+secret构成的某加密算法）。

sso server

sso server在attach操作中，先检测checksum是否有效，然后建立用户和sso server之间的session信息。并返回给用户SESSIONID的cookie信息,attach操作结束。

浏览器重新发起请求

由于attach操作后，页面再次重复此前的操作，所以表面上来看，前几步操作是重新走一次的。但是，由于本次操作中，和原有操作对比的话，已经存在了两个新的cookie。一个来自broker的sso_token_{broker}，另外一个来自sso server的SESSIONID.

所以，并不会真正的执行attach操作。接下来的操作是服务器端到sso server上获取用户信息，正常情况下，由于是第一次操作，是不会获得到相关信息的，跳转到broker的登陆页面。

broker登陆页

broker登陆页面，重新执行attch操作，简单检测完cookie后就完成attach操作。用户第一次操作，无法检测到用户信息，也无法获得用户提交的数据，所以，显示用户登陆表单。

用户填写用户名密码，再次post到登陆页面。经过简单的cookie对比，略过attach操作。进入到用户名密码验证环节。

broker验证用户名密码

broker拿到表单post过来的用户名和密码后，需要和sso server进行通信，执行login操作。这个时候，拿到了用户信息，跳转回首页，显示用户信息。此过程中，没有用户和sso server的直接操作，都是broker从中间代劳。

访问第二个broker

流程上和上述基本一致，但是执行attach操作的时候，307到sso server的浏览器，是带着SESSIONID这个cookie的。所以，两个broker在当前用户token上面达成了一致。所以在用户登陆操作检测过程中，自动登陆成功。

退出登陆

也是通过当前broker和sso server进行通信，执行logout操作，这个也是服务器端操作。用户和sso server之间，并没有直接产生联系。sso server直接注销所有的cookie。

总结

本文从逻辑走向角度，描述了sso应用的典型场景。侧重于形式，而没有触及本质。当然，由于所用范例的局限性，截图中的cookie发送部分，其实和最终的效果，还是有所差距的。不过，大体的逻辑流程是说明白了。对于细节cookie方面，在后面的文章中，苏南大叔还会做更详细的说明。

• https://newsn.net/tag/sso/

如果本文对您有帮助，或者节约了您的时间，欢迎打赏瓶饮料，建立下友谊关系。
本博客不欢迎：各种镜像采集行为。请尊重原创文章内容，转载请保留作者链接。