请注意,本文编写于 1363 天前,最后修改于 1321 天前,其中某些信息可能已经过时。
1. 单一服务器模式
这也是最传统的模式
一般过程如下:
- 用户向服务器发送用户名和密码。
- 验证服务器后,相关数据(如用户名,用户角色等)将保存在当前会话(session)中。
- 服务器向用户返回session_id,session信息都会写入到用户的Cookie。
- 用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。
- 服务器收到session_id并对比之前保存的数据,确认用户的身份。
缺点:
- 单点性能压力,无法扩展。
- 分布式架构中,需要session共享方案,session共享方案存在性能瓶颈。
2. SSO(Single Sign On)模式
分布式,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)
缺点:
- 占用带宽
- 无法在服务器端销毁
基于该方式,我们有了现在主流的JWT
基于微服务开发,选择token的形式相对较多,因此很多项目使用token作为用户认证的标准
推荐阅读:
版权属于:乐心湖's Blog
本文链接:https://www.xn2001.com/archives/534.html
声明:博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!