本文将以通俗易懂的方式阐述单点登录的流程，在这之前你可以阅读下比较官方的介绍单点登录。在阅读本文章之前，希望你对单点登录有一定的了解。
话不多说，直接上单独登录流程：
三个系统
系统A
认证系统B
系统C
-
流程1
请求访问受保护系统A，系统A对请求进行拦截(Filter)，拦截器会读取Cookie信息，获取token(登录凭证)，调用认证系统B校验token是否有效，如果token为空获取token失效，Filter会将请求重定向到认证系统B的登录页面 -
流程2
用户在认证系统登录成功后，将token存储在Cookie中，然后重定向到A系统中，并在将token作为请求参数(此时浏览器中存储了系统B的Cookie) -
流程3
重定向到系统后A后，Filter拦截到请求参数token，然后对token进校验，认证通过，将token存储Cookie中(此时浏览器中存储了系统B，系统A的Cookie) -
流程4
用户请求系统C，Filter拦截到用户无token信息，将请求转发到认证系统B -
流程5
请求转发到认证系统B后，系统B也会经过Filter，系统B发现当前Cookie中有token且有效，将请求又重定向到系统C，并将当前token作为请求参数 -
流程6
流程6和流程3一样，Filter获取到token后，对token进行认证然后存储到Cookie中
在访问受保护资源时，都会从Cookie中读取token，验证权限。李姐单点登录的关键在于浏览器中存储的是A、B、C三个系统的Cookie。
Filter的作用：
首先从Cookie中获取token，然后再从请求参数中获取token，然后对token进行校验，校验成功，将token存储到Cookie中，其实3个系统使用的Filter都是同一个。系统A、C对token进行认证也是调用的是认证系统B的服务。
可能有的用户会认为认证系统B在转发到系统A、C的时候直接将token做请求参数不安全？
解决方式：可以采用OAuth2.0的授权码模式，在转发时携带参数为AppId，通过AppId获取token，然后将token存储到Cookie
推荐一个简单易懂的开源SSO
如有对单点登录李姐出错或者不合理地地方，欢迎各位指出！！！