认证方案的设计与思考
登录设计一件看似简单却很复杂的事，其中用户认证是是登录的核心功能
主流认证方式
目前业界主流的认证方式主要包括：
| 认证方式 | 特点 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Session | 有状态，服务器端存储 | 传统单体应用 | 实现简单，安全性高 | 服务器压力大，不易扩展 |
| Token | 无状态，客户端存储 | 分布式系统 | 易于扩展，减轻服务器压力 | 需要额外的存储机制 |
| JWT | 自包含，无状态 | 微服务架构 | 无需存储，易于扩展 | 无法主动失效 |
| AccessKey | API密钥 | 服务间调用 | 简单直接 | 安全性相对较低 |
我们主要是业务SaaS平台，所以基于项目的方案重点对比分析Token和JWT两种认证方案。
当前Token认证架构
我们目前采用基于Token的认证方案，整体架构如下：
graph TB
A[用户发起登录请求] --> B{选择登录方式}
B -->|前台登录| C[Web Frontend Login]
B -->|后台登录| D[Admin Login]
B -->|小程序登录| E[Mini Program Login]
B -->|三方授权| F[Third-party Auth]
C --> C1[WebLoginRequest]
C1 --> C2[webLogin方法]
C2 --> C3[FrontLoginResponse]
C3 --> C4[登录成功]
D --> D1[AdminLoginRequest]
D1 --> D2{验证方式}
D2 -->|账号密码| D3[adminLogin方法]
D2 -->|第三方授权| D4[adminLoginAuth方法]
D2 -->|查询登录状态| D5[adminLoginInfo方法]
D3 --> D6[AdminLoginResponse]
D4 --> D6
D5 --> D6
D6 --> D7[后台登录成功]
E --> E1{小程序登录类型}
E1 -->|手动登录| E2[MinaLoginRequest]
E1 -->|自动登录| E3[MinaAutoLoginRequest]
E2 --> E4[minaLogin方法]
E3 --> E5[minaAutoLogin方法]
E4 --> E6[MinaLoginResponse]
E5 --> E6
E6 --> E7[小程序登录成功]
F --> F1[AdminLoginRequest]
F1 --> F2[adminLoginAuth方法]
F2 --> F3[AdminLoginResponse]
F3 --> F4[三方授权登录成功]
C4 --> G[获取用户Token]
D7 --> G
E7 --> G
F4 --> G
G --> H[存储登录状态]
H --> I[返回登录信息]
I --> J{后续操作}
J -->|获取用户信息| K[adminLoginInfo]
J -->|获取手机号| L[currentUserPhone]
J -->|退出登录| M[Logout]
M --> M1{退出类型}
M1 -->|前台退出| M2[frontLogout]
M1 -->|后台退出| M3[adminLogout]
M1 -->|小程序退出| M4[minaLogout]
M2 --> M5[清除前台Token]
M3 --> M6[清除后台Token]
M4 --> M7[清除小程序Token]
M5 --> M8[退出完成]
M6 --> M8
M7 --> M8
架构说明
上述流程图清晰展现了当前Token认证的核心处理逻辑：
- 登录流程：用户通过多种渠道（Web前端、管理后台、小程序、第三方授权）发起登录请求
- Token生成：后端验证用户身份后，生成唯一Token并存储在Redis中
- Token存储：前端将Token保存在LocalStorage中，用于后续请求
- 身份验证：每次API请求携带Token，后端验证Token有效性完成鉴权
当前方案分析
优势
无状态架构：不依赖Session维护状态，便于系统横向扩展
集中管理：用户信息存储在Redis中，便于查询和管理
主动控制：Token由服务端签发，支持主动失效和管理
跨域支持：天然支持跨域请求，适合前后端分离架构
问题
但是我们会发现一个很重要的问题，就是过期时间如何设置？太长了，token如果泄露就会遭受很长一段时间的重放攻击，太短用户体验又太差
如何升级
所以就可以考虑引入双Token机制
架构流程
优势
通过双token的方式，我们可以设置一个短时间的token进行业务鉴权。如果泄露了，时间窗口也比较短。剩下一个长时间的token就专门用来换取新的短时间token，也就是常说的无感刷新。
问题
但是又又一个新问题，可能也不能算问题。当我们使用token换取的时候，一般会有两步，从redis中获取用户标识，存在则认为校验通过，然后通过用户标识去查询用户信息最后返回。也是会有额外的开销，那我们是不是还可以把redis这一步也省略了。
如何升级
基于这个想法，就有了JWT。JWT是一个自包含、自验证的Token标准。
优势
- 自包含：Token本身包含了用户基本信息，无需额外查询
- 自验证：通过数字签名验证Token完整性和真实性
- 无状态：服务端无需存储Token状态，减轻服务器压力
验证流程：
- 后端接收到JWT后，直接验证签名有效性
- 签名验证通过后，从Payload中提取过期时间判断Token是否有效
- 提取用户ID等信息，直接查询数据库获取完整用户信息
- 整个过程完全省去了Redis查询环节
问题
但是问题又又又来了，我们现在不能主动管理jwt了，一旦jwt泄露了，我们想踢都踢不掉。
混合解决方案
为了兼顾JWT的性能优势和主动管理的安全性，就可以采用JWT + Redis黑名单的混合方案：
JWT方案设计
优势
自然是减少了redis的开销
问题
但是也会问题，例如如何管理黑名单，管理好用户和jwt的关联。兜兜转转回来可能还是需要redis
总结
认证方案的设计需要在安全性、性能、用户体验和实现复杂度之间找到最佳平衡点。没有放之四海而皆准的完美方案，只有最适合当前业务场景的技术选择。 但是安全是一个持续的过程，而非一次性的选择。
设计之初也很难考虑全场景也不可能考虑全。很多时候只有遇到问题了才能去推动改进。
你如果对认证方案有什么不同的见解？或者在落地时踩过哪些坑？欢迎来我的公众号【9号达人】一起交流，探讨技术的更多可能性。
