微服务认证选型：Spring Security、Sa-Token 与自研方案
工程判断： Spring Security、Sa-Token 和自研 Token 分别代表完整安全生态、轻量会话框架和项目定制协议。只看流行度或 API 简洁程度，无法决定哪一种适合当前微服务。
选型至少要验证登录、撤销、权限传播、异常响应、测试成本和未来协议扩展。没有同一组 PoC 证据，所谓对比往往只是偏好。
MetaLite 的现状可以作为自研方案样本，但不是预设赢家。本文用责任清单和退出条件比较三种路线，并通过 MetaLite 源码标出自研团队真正需要长期维护的部分。
一、先列责任，不先比较代码行数
| 责任 | Spring Security | Sa-Token | MetaLite 当前自研 |
|---|---|---|---|
| 标准认证与授权协议 | 生态完整，适合 OAuth2/OIDC、资源服务器 | 更偏项目会话与权限 API | 当前不是标准 OAuth2/OIDC 实现 |
| 登录与会话 | 需要按体系配置 | 提供常见会话能力 | UserAuthService 与 Redis Token Key 自行维护 |
| 踢人下线与并发会话 | 需要选定状态模型 | 有现成能力可评估 | 双向索引和全端撤销仍需补闭环 |
| 外部请求签名与加解密 | 通常由业务网关扩展 | 仍需项目集成 | 已进入 MetaLite 有序处理器链 |
| 内部身份传播 | 需结合项目 RPC 体系 | 需结合项目 RPC 体系 | InternalServiceClient 写入内部 Header |
| 资源权限与数据权限 | 可使用方法安全并自行接业务事实 | 可使用权限 API 并自行接业务事实 | ApiPermissionHandler 已接资源，数据权限尚未接 SQL |
| 安全升级与维护 | 跟随成熟生态但要处理升级 | 跟随框架并理解其状态模型 | 团队承担设计、测试和漏洞响应全部责任 |
二、MetaLite 真正不能轻易替换的不是 Token 字符串
外部请求同时包含 appId、timestamp、sign、userToken 和明文或密文业务参数。CallerAuthHandler 先恢复调用方身份，UserAuthHandler 再恢复用户身份，之后才进入解密和内部调用。
因此更换认证方案时，可以替换 Token 签发与会话存储，却不能直接删除调用方签名、请求类型、ThreadContext 和内部 Header 传播。这些属于 MetaLite 的外网协议和服务边界，不属于某个登录框架自动接管的范围。
三、选择 Spring Security 时要迁移什么
出现企业 IdP、OAuth2/OIDC、JWT Resource Server、标准授权服务器或方法级安全要求时，优先评估 Spring Security。
合理的接入不是把现有网关全部推倒，而是让标准认证结果适配成 MetaLite 的内部身份上下文，同时保留调用方签名和业务参数治理。需要重点验证安全上下文与 ThreadContext 谁是事实来源、异常码如何转换、网关和内部服务是否重复认证。
四、选择 Sa-Token 时要迁移什么
如果项目主要是国内企业后台，希望快速获得登录、会话、踢人下线、并发控制或 SSO，可以评估 Sa-Token。
替换清单至少包括：Token 创建、Redis Key、登录设备、续期、注销、权限查询和异常响应。MetaLite 的 ExternalLoginReq、appId 绑定、内部 Header 与资源权限仍需适配，不能把"加入依赖"当成迁移完成。
五、继续自研必须接受哪些硬责任
当前方案只有在团队愿意长期维护时才成立。验收底线包括：
text
密码学安全随机 Token
Token 与 appId/会话范围绑定
创建、换发和撤销原子化
旧 Token 无法继续使用
密码修改、禁用账号立即收敛
Redis 故障策略明确
日志绝不输出完整凭证
内部身份 Header 不能从公网伪造
认证、功能授权和数据授权分别测试MetaLite 当前分层骨架清楚，但安全随机 Token、完整撤销、nonce 防重放和数据权限执行链仍有强化空间。自研文章必须同时公开这些缺口。
六、三条迁移路线的最小 PoC
不要在会议里凭印象选型。为三条路线各实现同一组用例：登录、两端同时在线、单端注销、修改密码全端下线、权限变化、Redis 短暂不可用、内部服务调用和公网伪造 Header。
记录的不只是能否成功，还包括修改的 MetaLite 类、引入的状态、失败时默认行为和后续升级责任。PoC 结果比"某框架更流行"更能支撑企业决策。
七、MetaLite 当前阶段的选择
在现有自定义业务网关协议和轻量后台场景下，继续保留自研链路有现实连续性；但它不是对 Spring Security 或 Sa-Token 的全面替代。
一旦标准协议、复杂 SSO 或安全审计成为核心需求，应重新评估成熟框架。真正专业的选型不是证明作者原来的选择永远正确，而是明确什么条件出现时必须改变选择。
八、最终决策顺序
text
需要 OAuth2/OIDC、企业 IdP 或标准资源服务器
→ 优先 Spring Security 生态
主要需要快速完整的会话治理
→ 评估 Sa-Token，并做协议适配 PoC
网关协议高度定制且团队能长期承担安全责任
→ 才继续维护自研认证三条路线都能完成登录。真正决定长期成本的，是撤销、权限变化、跨服务身份、安全升级和故障响应由谁负责。
九、PoC 记录表必须留下可比较证据
| 用例 | 修改文件数 | 新增状态 | 故障默认行为 | 是否通过 |
|---|---|---|---|---|
| 登录与过期 | 待实测 | Token/Session | 明确错误码 | |
| 单端与全端注销 | 待实测 | 设备或会话索引 | 旧凭证必须失败 | |
| 权限变化 | 待实测 | 权限缓存/版本 | 最坏收敛时间 | |
| Redis 故障 | 待实测 | 本地兜底或无 | 拒绝/降级 | |
| 内部身份传播 | 待实测 | Header/安全上下文 | 禁止公网伪造 |
表格故意不预填"谁更好"。只有在同一 MetaLite 分支上完成三种最小 PoC，数字和失败行为才是项目自己的证据。
十、不要用流行度替代退出条件
选型文档还要写清退出条件：标准协议成为刚需时退出纯自研；团队无法持续维护会话安全时退出自研；Sa-Token 的状态模型无法适配外网协议且适配成本持续增加时重新评估；Spring Security 配置复杂不是退出理由，无法满足业务或团队没有维护能力才是。
明确退出条件，可以避免技术选择变成身份认同。
合并后的选型结论
选型比较的不是 Token 字符串怎样生成，而是谁负责请求协议、调用方认证、会话撤销、权限衔接和失败审计。应使用同一份责任清单与最小 PoC 比较三类方案，避免重复讨论框架背景和登录链表象。
框架简介
MetaLite 是面向企业生产环境的新一代 Java 微服务技术底座。系列文章重点分享代码背后的设计思路、技术取舍与工程实践。
源码基线
JDK 21、Spring Boot 3.2.9、Spring Cloud 2023.0.1、Spring Cloud Alibaba 2023.0.1.3，具体组件版本以项目 backend-bom 为准。
作者简介
15 年 Spring 体系企业级开发经验，专注于 Java 微服务架构、工程治理与生产实践。
持续更新
MetaLite 系列内容将持续更新，围绕核心设计、源码链路、技术取舍与生产实践展开。欢迎关注作者，及时获取后续内容。
在线演示
演示地址: https://admin.metalite.top/
演示账号: guess
演示密码: admin@2026