微服务间OAuth令牌校验及合法过期令牌的新令牌生成策略

当前做法的核心风险 #

服务B直接用客户端凭证生成新令牌的路子不安全：客户端凭证是服务级别的敏感密钥，一旦泄露就可能被滥用；而且这种方式完全跳过了用户身份校验，新令牌根本没法和原请求的合法用户绑定，权限管控等于虚设。

安全可行的实现方案 #

1. 用上KeyCloak自带的刷新令牌机制 #

• 服务A第一次获取访问令牌时，顺便请求刷新令牌（Refresh Token），KeyCloak会同时返回access_token和refresh_token。
• 服务A得把刷新令牌妥善存储，建议加密存储，别明文暴露。
• 当服务A检测到访问令牌即将过期，或者收到服务B的令牌过期提示，直接用刷新令牌向KeyCloak的令牌端点发起请求换新令牌：

  POST /realms/{你的领域名}/protocol/openid-connect/token
  Content-Type: application/x-www-form-urlencoded
  
  grant_type=refresh_token&client_id={你的客户端ID}&client_secret={你的客户端密钥}&refresh_token={已获取的刷新令牌}
  

• 服务B只需要专注校验访问令牌的合法性（签名、受众、过期时间等），不用自行生成令牌，彻底避开客户端凭证滥用的风险。

2. 优化服务B的令牌过期处理逻辑 #

• 服务B校验令牌发现过期时，别自己生成新令牌，直接返回401 Unauthorized，同时在响应头里添加WWW-Authenticate提示服务A用刷新令牌换新令牌：

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Bearer error="invalid_token", error_description="令牌已过期", error_uri="https://keycloak.example.com/docs/errors#invalid-token"
  

• 服务A收到该响应后，自动触发刷新令牌流程，拿到新令牌后重新发起请求，业务流程不会中断。

3. 给刷新令牌加安全配置 #

• 在KeyCloak控制台为客户端设置合理的刷新令牌过期时间：设置较短的绝对过期时间，同时启用滑动过期（Sliding Expiration），确保用户持续操作时刷新令牌不会过期，但长时间闲置后自动失效。
• 开启刷新令牌轮换（Refresh Token Rotation），每次使用刷新令牌获取新令牌时，KeyCloak会返回新的刷新令牌，旧的刷新令牌立即失效，避免被重复利用。

这套方案的优势 #

• 完全符合OAuth 2.0规范，令牌生成全由KeyCloak管控，避免服务B拿着客户端凭证违规操作。
• 刷新令牌与原用户身份绑定，新生成的访问令牌继承原用户的权限，保证业务请求的身份一致性。
• 令牌生命周期统一在KeyCloak管理，后续调整安全策略直接在控制台操作即可，维护成本低。

内容的提问来源于stack exchange，提问作者RathanaKumar