Technical documentation
刚撤销权限用户还能访问？微软 Entra ID 令牌机制导致的时间差真相
刚撤销权限用户还能访问？微软 Entra ID 令牌机制导致的时间差真相
微软 Entra ID 权限撤销存在时间差，因用户手中未过期的令牌仍被资源服务器认可，导致撤权后访问在窗口期内继续有效。
为什么撤权请求发出后，用户还能继续访问？
撤权请求发出后用户仍能访问，是因为身份平台从启动撤销到实际阻断之间存在不可忽略的延迟窗口期。
你刚在后台点击“撤销权限”，下一秒用户却仍能打开应用。别急着怀疑系统故障，这其实是身份平台集中式管理带来的必然时间差。微软官方文档也明确承认：从启动访问撤销到访问实际被阻断之间，存在一段不可忽略的窗口期 [1]。
这段“发起—生效”的间隔，源于控制平面与资源平面的物理分离。当你在目录中禁用账号或移除角色时，日志里显示的“操作成功”，仅代表控制平面接收并记录了变更 [1]。它并不等同于资源侧已经切断连接。只要用户手中的访问令牌尚未过期，或者刷新令牌仍有效，资源服务器就会依据这些旧凭证放行请求 [1]。
这种设计并非 Entra ID 独有，但各系统的表现差异巨大。不能因为 Entra ID 存在延迟，就默认所有 SaaS 应用或 API 网关都遵循相同的传播规则。审计时必须警惕一个误区：把“撤销任务完成”等同于“全部有效权限已消失”[2]。真正的阻断需要等待令牌自然失效或缓存被强制清除，而非仅看目录侧的操作日志。
这里有一个常被外行误解的细节：很多人以为撤销指令会像“断电开关”一样瞬间切断所有连接。实际上，现代分布式架构为了性能，资源服务器（如 AWS Lambda、Kubernetes Ingress 或 Azure Functions）往往会在本地缓存令牌的签名密钥和状态信息，甚至直接信任令牌的有效期而不再实时查询身份源。这意味着，即使目录侧已经标记为“拒绝”，资源服务器的本地缓存可能还在“按兵不动”，直到下一次策略刷新周期到来。这种“本地信任优先于全局同步”的机制，是造成时间差的根本技术原因，而非单纯的网络延迟。
| 层面 | 动作发生地 | 记录内容 | 对用户的实际影响 |
|---|---|---|---|
| 控制平面 | Entra ID 目录 | 禁用/移除角色日志 | 变更被接收，新请求将被拦截 |
| 资源平面 | 目标应用/API | 无即时更新记录 | 旧令牌仍被视为合法，访问继续 |
| 时间差 | 两者之间 | 令牌有效期剩余时间 | 权限看似失效，实则仍在运行 |
理解这一机制，才能准确界定审计结论。撤销指令只是发令枪，真正停止访问的是令牌的生命周期结束。
深入解密：访问令牌与刷新令牌是如何让旧权限“赖着不走”的
访问令牌与刷新令牌的有效期机制使资源服务器在票据过期前无需查询目录最新名单，从而放行旧权限请求。
你能看到用户明明已被移除角色，却依然能操作后台系统，靠的是什么？不是系统坏了，而是令牌机制在中间挡了一刀。认证完成后，系统评估授权策略，随即签发两张关键票据：访问令牌和刷新令牌 [1]。只要这两张票还在有效期内，资源服务器就不会去查目录里的最新名单，直接放行请求。
访问令牌：资源服务器的“一次性通行证”
访问令牌是用户手中的短期凭证。它包含签名、有效期和权限范围。资源服务器收到请求时，只验证签名是否合法、时间是否过期。它不实时连接身份目录去核对“这个人现在是不是员工”。这就好比一张纸质门票，检票口只看票面日期和防伪标，不会打电话问前台“这张票刚作废了吗？”[1]。因此，即使目录侧已经记录了禁用或撤销请求，只要手中的访问令牌没到点，资源服务器就继续信任并放行。
刷新令牌：维持长期访问的“隐形钥匙”
如果访问令牌用完了怎么办？系统还留了一把备用钥匙——刷新令牌。它允许应用在后台静默获取新的访问令牌，无需用户重新登录。这把钥匙通常比访问令牌寿命更长。一旦刷新令牌生效，新签发的访问令牌会延续之前的权限配置。这意味着，即便你在目录里把用户踢了，只要他手里的刷新令牌还没过期，就能不断续命，让旧权限一直“赖着不走”。[1]
为了看清这两者在权限失效过程中的不同表现，我们可以对比它们的行为特征：
| 对比项 | 访问令牌 (Access Token) | 刷新令牌 (Refresh Token) |
|---|---|---|
| 主要用途 | 直接携带权限调用资源 API | 用于换取新的访问令牌 |
| 有效期 | 短（通常 1 小时以内） | 长（数天至数月不等） |
| 验证方式 | 仅校验签名与时间戳，不查目录 | 需向身份服务发起交换请求 |
| 失效触发 | 到期即废，无法再使用 | 被撤销后无法换取新票 |
| 缓存影响 | 本地或网关缓存可延长使用窗口 | 若未清除，可持续生成有效会话 |
这种设计虽然提升了用户体验，却制造了权限控制的真空期。目录对象禁用、角色移除或撤销请求的成功日志，至多证明控制平面接受了变更；若要确认动作真正生效，必须等待令牌自然过期或主动清除缓存 [1]。否则，审计结论不能简单地把“撤销任务完成”等同于“全部有效权限已消失”。
此外，不同的应用场景下，令牌的“赖皮”程度也大不相同。例如，在传统的单体 Web 应用中，用户关闭浏览器通常意味着会话结束，时间差较短；但在移动端 App 或单页应用（SPA）中，由于采用了持久化存储和自动刷新机制，刷新令牌可能长达 30 天甚至更久。更有甚者，某些企业级应用会将令牌缓存在负载均衡器（如 F5、Nginx）的内存中，导致即使后端应用层感知到了撤销，流量入口依然放行。这种跨层级的缓存叠加，使得“撤销”的生效时间在某些极端场景下可能被拉长到数小时。
如何正确理解审计日志中的“撤销成功”与实际权限状态
审计日志中的“撤销成功”仅代表控制平面指令已记录，实际权限失效需等待分散网关处的令牌过期或缓存清除。
很多运维人员看到控制台显示“撤销任务完成”，便默认该用户已彻底失去访问能力。这种认知存在致命偏差：控制平面的动作记录，并不等同于资源侧的权限即刻失效 [1]。目录服务只是发出了指令，而真正执行拦截的是分散在各处的网关与应用。只要手中的令牌未过期，或者本地缓存尚未刷新，旧权限就会像幽灵一样继续生效。
为何不能假设所有系统都具备统一的传播上限
试图用一套标准去衡量所有系统的响应速度是不现实的。不同架构下的资源服务器拥有各自独立的缓存策略和刷新频率，缺乏跨应用的统一关联标识与端到端确认协议 [3][4]。这意味着，集中式身份平台发出的撤销信号，在不同组件间的传播路径和耗时完全不可控。
下表展示了控制平面动作与资源侧实际反应之间的典型差异：
| 对比维度 | 控制平面（Entra ID） | 资源侧（网关/应用/API） |
|---|---|---|
| 核心动作 | 接收并处理撤销请求 | 验证令牌有效性或检查缓存 |
| 状态反馈 | 立即返回“操作成功”日志 | 可能继续放行未过期的旧令牌 |
| 数据依据 | 基于目录对象的最新状态 | 基于本地缓存或本地会话记录 |
| 传播机制 | 无统一的全局广播协议 | 依赖各自独立的刷新周期 |
| 最终结果 | 仅证明变更被受理 | 需结合拒绝记录才能确证权限终止 |
这种架构上的割裂意味着，你不能简单地将“任务完成”等同于“全部有效权限已消失” [2]。如果缺乏资源侧的直接证据，所谓的“撤销成功”只是一个局部事实，而非全局结论。
因此，审计结论必须保持克制。不要断言权限已完全清除，除非你看到了具体的拒绝记录。集中式平台的控制功能虽然强大，但过度依赖单一状态会埋下隐患 [1]。真正的安全闭环，需要建立从身份平台到具体资源端的端到端验证机制。只有当网关日志明确记录了拒绝请求，或应用返回了鉴权失败时，才能确认那次撤销动作真正生效。否则，那只是一场发生在后台的独角戏。
实操建议：在进行高风险权限审计时，不要仅依赖 Entra ID 的“撤销成功”日志。建议立即模拟一次该用户的访问请求（或在测试环境中复现），观察目标应用是否返回 401 Unauthorized 或 403 Forbidden。如果应用仍返回 200 OK 并返回数据，说明令牌尚未失效或缓存未更新，此时应判定为“权限撤销未完成”，并持续监控直至出现明确的拒绝响应。这一步骤是验证权限真实落地的唯一金标准。
常见问题解答 (FAQ)
Q: 既然有延迟，有没有办法立刻阻止用户访问？ A: 除了等待令牌自然过期，最激进的方法是强制用户退出所有会话（Sign out all sessions），但这通常要求用户主动配合或在特定配置下由管理员触发。对于已分发的令牌，最稳妥的方式仍是依靠其生命周期结束。
Q: 刷新令牌被撤销后，旧的访问令牌还能用吗？ A: 这是一个常见的误区。刷新令牌被撤销后，用户无法再获取新的访问令牌。但是，如果旧的访问令牌尚未过期，它依然可以继续使用，直到其自然失效。这就是为什么我们需要关注两种令牌的状态。
Q: 如何判断权限撤销是否真正生效？ A: 不要只看 Entra ID 的控制台日志。必须检查目标应用或 API 网关的日志，寻找明确的”401 Unauthorized”或”403 Forbidden”错误码，这才是权限真正被阻断的铁证。
参考来源
- Revoke user access in an emergency in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn · https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access（A级）
- Identity Lifecycle Management Playbook - IDManagement · https://www.idmanagement.gov/playbooks/ilm/（A级）
- draft-liu-oauth-chain-delegation-00 - Delegation Chain for OAuth 2.0 · https://datatracker.ietf.org/doc/draft-liu-oauth-chain-delegation/（A级）
- draft-niyikiza-oauth-attenuating-agent-tokens-01 - Attenuating Authorization Tokens for Agentic Delegation Chains · https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/（A级）