认证方案的设计与思考

登录设计一件看似简单却很复杂的事，其中用户认证是是登录的核心功能

主流认证方式

目前业界主流的认证方式主要包括：

认证方式	特点	适用场景	优势	劣势
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号达人】一起交流，探讨技术的更多可能性。