KeyCloak令牌刷新时sub值不匹配及OIDC服务器用户判定逻辑咨询

OIDC服务器判定令牌所属用户的核心依据 #

OIDC服务器（包括KeyCloak）判定令牌所属用户，完全基于refresh token本身绑定的用户身份，和nonce无关：

• 用户首次获取refresh token时，KeyCloak会将该令牌与用户ID（sub）、会话ID（sid）、session_state做绑定并存储在服务器端。
• 刷新令牌时，KeyCloak会先验证refresh token的签名、有效期、客户端权限等，再根据令牌绑定的用户信息生成新的access token。

你的问题分析 #

1. 为什么sub不匹配但sid/session_state一致？ #

这种情况的核心原因是同一个KeyCloak会话被错误关联到了不同用户，常见场景包括：

• 应用端会话管理bug：比如缓存、Cookie存储逻辑出错，将用户A的refresh token意外给到了用户B的请求上下文，导致用A的refresh token刷新时返回了B的access token（反之亦然）。
• KeyCloak会话配置异常：比如会话超时设置过长，或者客户端开启了不合理的会话共享机制，导致不同用户复用了同一个服务器端会话。

2. nonce的作用与你的错误用法 #

• nonce的唯一作用是防止授权码流程中的重放攻击，仅在authorization code grant的初始授权请求中需要携带，刷新令牌流程（refresh_token grant）根本不需要传递nonce。
• 你所有刷新请求用同一个nonce，不会直接导致用户混淆，但这是违反OIDC规范的不安全做法，可能被利用进行重放攻击，建议立即停止在刷新请求中携带nonce。

排查与修复建议 #

• 检查应用端会话逻辑：排查是否存在不同用户的refresh token被混存、复用的情况，比如会话存储（如Redis、Cookie）是否正确隔离了不同用户的令牌。
• 验证refresh token的绑定关系：调用KeyCloak的/realms/{realm}/protocol/openid-connect/token/introspect端点，传入问题refresh token，查看返回的sub字段，确认该令牌实际绑定的用户是否与你预期一致。
• 检查KeyCloak客户端配置：确认客户端是否开启了Allow Offline Access，如果开启，检查离线令牌的生命周期配置是否合理；同时检查客户端的会话超时设置，避免过长时间的会话复用。
• 查看KeyCloak日志：定位出现问题的请求，查看服务器端日志中关于令牌验证、会话关联的记录，寻找用户身份切换的异常线索。

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