令牌撤销政策失效咨询：密码变更后access_token仍可正常使用

首先，这种情况里的部分现象是符合设计逻辑的，但refresh_token还能正常使用的话大概率是有配置或者测试环节需要确认的地方，我来拆解一下：

Access Token 继续可用是正常设计 #

Access Token本身是无状态的短期令牌（默认有效期1小时），Azure AD在签发后，服务端不会实时去校验用户的密码状态——毕竟每次请求都查用户密码状态会极大影响性能。文档里提到的“用户更改密码后需重新进行身份验证”，指的是当现有token过期，或者需要通过refresh_token获取新token时，必须使用新密码重新完成身份验证，而不是让已签发的有效token立即失效。

所以在access_token的有效期内，即使密码变更，它依然能正常调用API，这是合理的。

Refresh Token 仍可用可能是配置或测试问题 #

正常情况下，用户更改密码后，Azure AD会自动撤销该用户的所有refresh_token，此时用旧的refresh_token请求新access_token应该会返回invalid_grant错误。如果你测试发现refresh_token还能正常使用，建议排查以下几点：

• 确认测试流程：改密码后，是否是用旧的refresh_token去请求新的access_token，而不是继续使用之前已经获取的未过期access_token？
• 检查是否启用了特殊的会话持久化配置：比如设备信任、长期会话等场景，可能会让refresh_token在密码变更后依然有效，但这属于特殊配置，默认不会开启。
• 查看条件访问策略：是否有自定义策略允许旧令牌继续生效？默认情况下Azure AD没有这类策略，但如果有自定义配置需要确认。

如何实现密码变更后令牌立即失效？ #

如果你的业务场景要求密码变更后所有令牌立即失效，仅靠Azure AD默认机制做不到（因为access_token无状态），可以考虑这些方案：

• 使用Azure AD的令牌撤销端点主动撤销指定的refresh_token或access_token（注意access_token的撤销需要服务端配合，客户端缓存的token无法强制失效）。
• 在你的应用服务端维护一个令牌黑名单，记录密码变更用户的ID或已撤销的token哈希值，每次验证token时先检查黑名单。
• 缩短access_token的有效期，把风险窗口降到最低。

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