用访问令牌替代静态密码需重构认证逻辑，包括可信授权服务器签发短期令牌、客户端标准Bearer头携带、服务端验证JWT签名与声明、双Token自动刷新及黑名单管理。
直接用访问令牌（Access Token）替代静态账号密码，不是简单“换一个字符串”，而是重构认证逻辑、更新传输方式、强化生命周期管理的一整套接入升级。核心在于把“凭证长期有效、客户端明文持有”的旧模式，换成“短期有效、服务端签发、客户端安全携带、自动刷新”的新模式。
第一步：明确令牌来源与签发方
不能凭空生成Token，必须有可信的授权服务器（AS）作为源头。常见路径有三类：
- 对接标准OAuth 2.0授权服务器：如Spring Authorization Server、Keycloak、Auth0等。客户端通过授权码模式（推荐）或客户端凭证模式获取Token，确保用户身份经由AS验证，而非直接传账号密码。
- 复用现有平台Token机制：例如OpenAI官方登录流程产出的Access Token + Refresh Token组合，或企业统一身份平台（如阿里云RAM、Azure AD）颁发的JWT。关键是拿到的是由权威方签名、含明确过期时间（exp）、可验证来源（iss）和受众（aud）的结构化令牌。
- 自建轻量Token签发服务：若系统较封闭，可基于JWT库（如Go的github.com/golang-jwt/jwt/v5、Java的jjwt）实现简单签发服务，但必须严格保管签名密钥（HS256私钥或RS256私钥），且禁止在客户端存储密钥。
第二步：改造客户端接入方式
所有调用方（Web前端、App、IoT设备、后端服务）不再拼接用户名密码，而是按规范携带Token：
-
HTTP请求头统一使用：
Authorization: Bearer <access_token>。这是RFC 6750定义的标准方式，兼容性最好，也避免Token出现在URL中被日志或代理意外记录。 -
禁用任何形式的明文凭证传递：删除所有含
username=xxx&password=yyy的POST参数、基础认证（Basic Auth）头、或硬编码在代码/配置里的API Key字符串。 - 移动端与Web端区别对待：移动端建议将Token存于安全存储（如Android Keystore、iOS Keychain）；Web端优先存在内存（避免localStorage被XSS窃取），配合HttpOnly Cookie存放Refresh Token（需同源且Secure标记）。
第三步：服务端验证与上下文重建
接收请求的服务（资源服务器）不再查数据库比对账号密码，而是验证Token有效性并提取身份信息：
- 校验签名与完整性：用公钥（RS256）或共享密钥（HS256）验证JWT签名未被篡改。
-
检查标准声明：确认
exp未过期、iat不过早、aud匹配本服务标识、iss是受信任的签发方。 -
解析Payload提取上下文：从Token中读取
sub（用户唯一标识）、scope（权限范围）、roles（角色）等字段，直接用于后续鉴权，无需再查用户表。 - 黑名单机制（可选但推荐）：对主动注销或异常令牌，维护一个短时效Redis黑名单（key为jti，ttl设为Token剩余过期时间），验证时额外检查是否在黑名单中。
第四步：建立令牌生命周期管理闭环
Token不是一劳永逸，必须配套刷新、续期、失效机制：
- 双Token机制落地：Access Token短时效（如15–60分钟），Refresh Token长时效（如7天）、仅用于换取新Access Token，且每次使用后应作废旧Refresh Token（滚动刷新）。
- 客户端自动刷新逻辑：前端拦截401响应，用Refresh Token向授权服务器申请新Access Token；失败则引导重新登录。避免用户感知中断。
-
服务端主动失效支持：提供
/revoke接口，允许用户登出或管理员强制下线时，使对应Refresh Token立即失效。
