用户单点登录

一、用户身份认证

1、单一服务器模式

我们使用传统的Session贺Coookie的模式,就可以完成单一服务器的登录,会话跟踪技术,
在这里插入图片描述
一般过程如下:
用户向服务器发送用户名和密码。
验证服务器后,相关数据(如用户名,用户角色等)将保存在当前会话(session)中。
服务器向用户返回session_id,session信息都会写入到用户的Cookie。
用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。
服务器收到session_id并对比之前保存的数据,确认用户的身份。
缺点:
单点性能压力,无法扩展。
分布式架构中,需要session共享方案,session共享方案存在性能瓶颈。,sesion由服务器产生,不同的服务器session无法共享。
我可以加以层来处理,多个服务器之前session不能共享的问题,
可以采用redis来存储共享信息,每次用户访问redis就行
session共享方案:
session广播:性能瓶颈,不推荐
redis代替session:推荐,性能高

2、SSO(Single Sign On)模式

CAS单点登录、OAuth2
在这里插入图片描述
我使用一个服务端负责专门的用户信息认证,每次将认证的信息存储到redis中,当用户再次访问时,先访问认证中心服务,查看redis是否存储用户信息,如果存储了那么就是已经登录的用户。
分布式,SSO(single sign on)模式:单点登录英文全称Single Sign On,简称就是SSO。它的解释是:在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。
如图所示,图中有3个系统,分别是业务A、业务B、和SSO。
业务A、业务B没有登录模块。
而SSO只有登录模块,没有其他的业务模块。
一般过程如下:
当业务A、业务B需要登录时,将跳到SSO系统。
SSO从用户信息数据库中获取用户信息并校验用户信息,SSO系统完成登录。
然后将用户信息存入缓存(例如redis)。
当用户访问业务A或业务B,需要判断用户是否登录时,将跳转到SSO系统中进行用户身份验证,SSO判断缓存中是否存在用户身份信息。
这样,只要其中一个系统完成登录,其他的应用系统也就随之登录了。这就是单点登录(SSO)的定义。
优点 :
用户身份信息独立管理,更好的分布式管理。可以自己扩展安全策略
缺点:
认证服务器访问压力较大。

3、Token模式

在这里插入图片描述
我的理解是:当客户端,发送用户登录请求的时候,先访问授权服务器,授权服务器进行合法性校验,然后分发一个”令牌“,用户可以拿着这这个令牌进入不同的服务器中,因为不同的服务器中有相同的校验令牌的机制,所以能够保证用户登录是否携带合法令牌
优点:
无状态: token是无状态,session是有状态的
基于标准化:你的API可以采用标准化的 JSON Web Token (JWT)
缺点:
占用带宽
无法在服务器端销毁

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

奋斗中的代码猿--刘同学

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值