如何信任应用会话与OIDC刷新令牌之间的关联

• 绝对不能直接信任原idtoken属于当前会话
  原idtoken已过期，本身不具备有效性，且无法确认OIDC提供商侧的用户会话是否已发生变更（比如用户在OIDC端登出、账号切换），跳过验证会引入身份冒充的安全风险。

• 优先通过现有资源完成身份一致性验证

  1. 用新获取的accesstoken调用/userinfo端点：既然业务逻辑原本依赖该端点的email启动后台会话，此时可借助新accesstoken调用该接口，拿到返回的sub字段，与服务器端会话中存储的原用户sub做比对。若一致，说明用户身份未发生变化，可继续使用当前会话，同时将新获取的用户信息（含sub）更新到服务器端会话中。
  2. 验证refreshtoken关联身份：部分OIDC提供商允许通过refreshtoken直接关联用户身份信息，但这种方式的可靠性远低于/userinfo接口，仅作为备选方案。

• 替代验证失败时，强制引导用户重新登录
  若调用/userinfo接口失败（如accesstoken权限不足、OIDC提供商不支持该接口），或返回的sub与服务器端存储的不一致，必须引导用户重新走OIDC登录流程，重新获取有效的idtoken和accesstoken，确保身份的一致性与安全性。

• 额外优化建议

  • 排查OIDC服务器不返回新idtoken的原因：确认请求刷新token时是否携带了scope=openid参数——多数OIDC提供商仅在包含该scope的刷新请求中返回新idtoken；同时检查OIDC提供商的后台配置，是否开启了刷新时返回idtoken的选项。
  • 调整会话存储策略：将用户的sub字段单独存储在服务器端会话中，而非仅依赖idtoken，这样即使idtoken过期，也有固定的身份标识用于后续验证。

内容的提问来源于stack exchange，提问作者Steven De Groote