单点登录实现方式

单点登录介绍：

在多个系统的环境下，同一个用户登录后，就不需要在其他系统中再次登录。也就是用户登录一次之后获得所有其他系统的信任。单点登录就是解决如何产生和存储所有系统的信任，再就是怎么验证这个信任的有效性。

• 如何存储信任凭证？
• 存储的信任凭证如何得到各个系统的验证？

如何存储信任凭证？

• 使用cookie作为存储用户的凭证。
  这个实现比较简单，就是将用户的凭证存放在cookie中，
  1.用户通过用户名密码在sso服务进行认证。认证通过返回认证后的凭证
  2.用户通过携带的授权的凭证请求子应用系统。验证通过就认为已经登录成功了。
  
  优点：
  实现比较简单。所有的认证信息只需要依赖于cookie就可以了。
  缺点：
  1.cookie不是很安全，而且用户禁止cookie后没有办法登录。
  2.不支持跨域实现免密登录。
  3.这种的验证要保证加密算法不被人知道，如果一旦泄露，攻击者就可以通过伪造cookie则可伪造用户身份。

• 通过jsonp方式回调返回凭证实现。
  
  使用jsonp的这种方式虽然能解决跨域的问题，但是安全性还是有些问题。加密算法被泄露就会存在问题。只是将存储的验证的加密凭证信息放在了jsonp接口返回的环节。如果用户直接伪造host和用户凭证请求子应用还是会存在风险。

• 以返回验证后的token值进行校验。
  

通过sso认证服务和子授权应用反复的重定向来进行验证。现有的大型系统大都是这种设计。
sso认证服务提供一个get方式登录接口。用户通过子应用重定向连接方式访问这个接口。如果用户没有登录成功则跳转到登录页面。如果已经登录生成加密的token令牌，并重定向到子应用提供token验证接口。通过解密校验登录子应用。

优点：
1.既可以处理跨域的问题。
2.还可以解决安全问题。由于所有的信息都在服务端。所以即使知道了加密算法也不能够登录，因为子应用还是会请求认证服务的接口返回的token进行验证。
缺点：项目调用比较复杂。

一般单点登录会用在发布多个应用实例的情况下。也会建立自己的用户中心。如果是后端的话会有用户的授权和用户的信息统一管理。
用户中心不处理业务逻辑，只会处理用户信息的管理以及授权第三方应用，
第三方用户登录时候将请求发送给用户中心认证校验。

用户中心和权限分离

还有就像我们公司会将用户中心和授权分离开来。这个有好处有坏处。好处就是调用端只需要配置到自己的应用相关的拦截。坏处是服务端依赖的都是统一的用户资源都需要进行远程调用。

有技术基础的具体看我的另外一个博文
https://blog.csdn.net/u013642886/article/details/90697541