SSO系统

一、什么是SSO系统？

单点登陆(SingleSignOn，SSO)，就是经过用户的一次性鉴别登陆。当用户在身份认证服务器上登陆一次之后，便可得到访问单点登陆系统中其余关联系统和应用软件的权限，同时这种实现是不须要管理员对用户的登陆状态或其余信息进行修改的，这意味着在多个应用系统中，用户只需一次登陆就能够访问全部相互信任的应用系统。

二、SSO系统实现原理？

这里用一张图说明sso流程

三、SSO系统实现？

假设zss系统前端域名为zsstest.zuel.com:8081,后端域名为zsstest.zuel.com:8887;sso系统前端域名为sso.zuel.com:8082,后端域名为sso.zuel.com:8888。咱们跟着原理流程图来说解如何实现单点登陆。

假设zss系统首页zsstest.zuel.com:8081/index有一个/api/getUserinfo请求获取用户信息，当第一次用浏览器打开首页时就发送了该请求，zss-os后端接收到该请求，发现请求没有携带cookie身份（也就是token），返回401给zss-fe前端，前端响应拦截器拦截到返回数据，发现返回数据为401，因而重定向到sso的登陆页（sso.zuel.com:8082/login），并把zss系统首页做为参数拼接到重定向地址的后面（window.location.href=http://sso.zuel.com:8082/login?service=http://zsstest.zuel.com:8081/index）。当登陆成功时，sso-os后端根据帐户和时间生成token（使用jwt包），经过设置响应头Set-Cookie属性种下cookie，并把token存到redis集群中，最后重定向到service参数url。

重定向到service参数url又会再次发送/api/getUserinfo请求，后端zss-os就会去校验cookie身份（到redis集群中去找是否有该身份的token存在），若校验合法，则返回请求结果，不然返回401又再次重定向到sso登陆页。

这里使用redis集群的目的是zss系统和sso系统均可以访问到redis存储的数据。

上面还有许多坑，在设置cookie时须要注意：

• 当前端配置withCredentials=true时, 后端配置Access-Control-Allow-Origin不能为*, 必须是相应地址
• 当配置withCredentials=true时, 后端需配置Access-Control-Allow-Credentials
• 当前端配置请求头时, 后端须要配置Access-Control-Allow-Headers为对应的请求头集合
• 后端设置的set-cookie若想在浏览器cookie中显示而且在前端请求头自动携带，那么设置cookie时domian就必须与前端当前页域名、请求域名同样。好比，上述domain设置为.zuel.com，那么zsstest.zuel.com:8081/index页面的cookie将会显示，zsstest.zuel.com:8887/api/getUserInfo请求头也会自动携带domain域名的cookie
• 只有name、path、domain相同的cookie才是同一个cookie

参考：
https://juejin.im/post/5c2490...
https://juejin.im/post/5c0f2a...
https://juejin.im/post/59d1f5...

单点登陆的实现：
上面生成token使用了时间，也就是每次登陆成功生成的token都会不一样，当用户A使用chrome登入系统生成的token为t1，redis存储t1，浏览器cookie存储t1，而后用户A换个Firefox登陆，生成token为t2，redis存储t2，浏览器cookie存储t2。当用户A在chrome刷新页面，请求携带的cookie仍是t1，但redis存储的cookie已经变成t2，因此身份验证不会经过，页面会重定向到sso登陆页

统一登录实现效果：

项目git地址