Technical documentation
撤销权限后为什么还能访问？因为令牌没过期
撤销权限后为什么还能访问？因为令牌没过期
撤销权限后仍可访问，是因为控制平面的指令执行与资源侧的实际拦截之间存在时间窗口，导致旧令牌或缓存数据暂时有效。
为什么点击“立即撤销”后，对方依然能打开文件？
点击立即撤销后对方仍能打开文件，是因为系统仅完成了控制平面动作，未过期的会话或令牌在时间窗口内依然被资源侧认可。
你刚刚在管理后台点击了“立即撤销”，系统也弹出了“操作成功”的提示。然而几分钟后，那位用户竟然还能顺利打开敏感文件。别急着怀疑系统故障，这其实是 Microsoft Entra ID 官方文档中明确指出的客观现象：从启动撤销到实际失效之间，存在一个不可忽视的时间窗口 [1]。
官方定义：从指令发出到生效的客观延迟
这个时间差源于系统评估授权策略并签发令牌的异步过程。目录侧生成的日志，只记录了控制平面接收并处理了变更指令，就像邮递员确认收到了退信单，并不代表收件箱里的旧信件已经自动销毁 [1]。若资源侧仍依据此前签发且未到期的令牌、会话或缓存作出判断，访问动作便不会立刻中断 [1]。
必须厘清的是，Entra 的特定流程不能推广至所有身份平台或 API 网关。其他系统的延迟机制可能完全不同，甚至没有这种间隔 [1]。因此，审计结论绝不能简单将“任务完成”等同于“权限消失”。把控制平面的接收动作当作最终结果，会掩盖资源侧仍在执行操作的真实风险 [2]。
目录侧显示“已撤销”，用户为何依然能操作？
目录显示已撤销但用户仍操作，源于控制平面与数据平面职责分离，资源侧判定逻辑可能仍在依赖尚未失效的旧状态数据。
你刚在管理后台看到某用户的权限状态变为“已撤销”，日志也显示指令执行成功。可下一秒，这个人还能访问核心数据。问题不在系统坏了，而在控制平面和数据平面的职责被切分开了。
旧令牌与新指令的冲突：资源侧的判断逻辑
目录侧（控制平面）只负责接收并记录变更指令。它把“用户已移除”写进日志，但这只是行政动作，不代表物理切断。资源侧（数据平面）才是真正放行或拒绝请求的守门人。[1]
关键在于令牌的生命周期。认证通过后，系统会为资源签发访问令牌（Access Token）和刷新令牌（Refresh Token）。[1] 这些令牌是数字钥匙，只要没过期，就具备法律效力。目录侧一旦发出撤销指令，若无法即时让资源侧丢弃这把钥匙，旧钥匙就能继续开门。
现有架构缺乏跨应用缓存、长期令牌及网关策略刷新之间的统一关联标识和端到端确认协议。[3][4][5][1][2] 这意味着，当控制平面说“停”时，数据平面可能还在用上一秒签发的令牌做判断。资源服务器依据本地缓存或持有的令牌决策，而非实时回查目录。若令牌未过期，资源侧会默认允许操作，导致审计数据出现偏差。
这种冲突并非特例，而是分布式系统的常态。为了降低运维成本，许多集中式身份平台默认撤销功能足够控制，无需逐资源验证。但材料并未给出传播上限或统一的清除协议。[1] 因此，目录里的“已撤销”只能证明控制平面接受了变更，不能代表资源侧已失效。
| 维度 | 控制平面（目录侧） | 数据平面（资源侧） |
|---|---|---|
| 核心职责 | 记录指令、更新状态 | 执行授权、放行请求 |
| 判断依据 | 接收到的变更日志 | 本地持有的令牌/会话 |
| 撤销响应 | 立即标记为“已撤销” | 依赖令牌过期或主动清理 |
| 时间窗口 | 几乎为零 | 取决于令牌剩余有效期 |
| 常见误区 | 认为日志即生效 | 忽略旧令牌的持续效力 |
要把这事想清楚，别把“指令发出”当成“动作完成”。目录侧的日志只是告诉世界“我想关掉灯”，但资源侧手里还攥着没关掉的开关。只有当旧令牌自然过期，或者资源侧收到明确的刷新信号，真正的访问才会停止。
这里有一个常被外行忽视的细节：你以为“刷新令牌”就是重新登录，其实它往往在后台静默运行。 很多开发者误以为用户只要不手动登出，刷新令牌就会一直有效，或者认为一旦管理员撤销权限，刷新令牌就会瞬间作废。事实是，刷新令牌通常拥有比访问令牌更长的生命周期（如数天甚至数月），且其吊销机制依赖于资源服务器主动去检查。如果资源服务器配置为“信任本地缓存”或“仅在令牌过期时检查吊销列表”，那么即使你在 Entra ID 里把用户删了，只要他手里的刷新令牌没过期，他的客户端就能在后台偷偷换出一张新的访问令牌，继续访问系统。这就是为什么有时候你撤销了权限，用户却能在几天内毫无察觉地继续操作——他们根本没有触发需要人工干预的“登录”动作，系统只是在后台自动续命。
如何判断真正的权限失效？避免审计误判
判断真正权限失效需跨越控制平面确认，因为集中式平台无法保证跨应用长令牌的即时同步，现有机制缺乏端到端确认协议。
集中式身份平台无法保证跨应用、长令牌的即时同步，现有材料甚至没有给出传播上限或端到端确认协议。[3][4][5][1][2] 这意味着你看到的“撤销成功”，往往只是控制平面完成了动作，资源侧的判定逻辑可能还在依赖旧数据。
审计视角的关键差异
运维中常有一种误区：认为无需逐资源验证即可认定权限失效。这种主张虽能降低验证成本，但缺乏统一关联标识支撑，容易导致审计误判。[3][4][5][1][2] 当系统评估授权策略并签发令牌后，目录对象禁用或角色移除的日志，至多证明变更已被接受。若资源侧仍依据此前签发且未到期的令牌、会话或缓存作出决定，就需要另有资源侧证据。[1]
为了看清这种差异，我们可以对比两种状态下的实际表现：
| 状态维度 | 控制平面（目录侧） | 资源侧（实际执行） |
|---|---|---|
| 触发信号 | 收到撤销指令并记录日志 | 接收具体访问请求 |
| 判定依据 | 检查当前用户属性是否匹配 | 验证手中令牌的有效性 |
| 响应结果 | 显示“任务完成”或“已撤销” | 返回“拒绝”或“允许” |
| 时间窗口 | 瞬间完成写入 | 取决于令牌过期时间或缓存刷新 |
| 关键风险 | 误以为权限立即消失 | 持有未过期令牌仍可通行 |
表格中的数据揭示了核心矛盾：目录侧的“已撤销日志”仅代表控制平面动作，若用户仍持有未过期的令牌，依然可以执行操作。[1][2] 审计结论必须明确区分“控制平面动作完成”与“权限实际消失”，避免将两者混为一谈。[1][2]
正确的做法是以资源侧的实际拒绝响应为准，而非仅看目录日志中的“任务完成”状态。[1][2] 审计报告中应避免使用绝对化描述，如“全部有效权限已消失”。建议记录时间窗口内的潜在访问行为作为风险提示，这才是对真实安全状态的客观还原。
针对这一痛点，建议实施“强制短效令牌 + 动态吊销检查”的组合策略。 不要仅仅依赖默认的令牌设置，而应主动调整策略：首先，将高敏感资源的 access_token 有效期缩短至 15-30 分钟，迫使客户端频繁发起请求；其次，在资源服务器的中间件层集成“吊销检查钩子（Revocation Hook）”，确保每次令牌刷新或高频访问时，都实时向身份提供商查询该令牌是否在黑名单中。这样，即使攻击者窃取了旧令牌，由于令牌寿命极短且每次使用都会触发实时校验，他们能利用的时间窗口将被压缩到秒级，从而在审计层面实现真正的“即时失效”。
常见问题解答 (FAQ)
Q: 如何缩短撤销后的访问窗口期？
A: 目前主要依赖缩短 access_token 的过期时间。通过配置更短的令牌生命周期，可以强制客户端频繁刷新，从而更快感知到目录侧的变更。此外，启用针对特定高风险应用的即时吊销机制也能起到辅助作用。
Q: 既然有延迟，那“目录侧已撤销日志”还有用吗？ A: 非常有价值。它是合规审计的第一道防线，证明了管理员确实执行了撤销操作。但它不能作为“用户已完全失去权限”的唯一证据，必须结合资源侧的实际访问日志进行交叉验证。
Q: 刷新令牌（Refresh Token）过期后会自动失效吗？
A: 是的。一旦 refresh_token 过期且未被续期，用户将无法获取新的访问令牌，此时即使旧的 Access Token 尚未过期，用户也无法发起新的请求。这是阻断访问的最有效手段之一。
参考来源
- 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级）
- draft-schrock-ae-challenge-08 - An Authorization Evidence Challenge for High-Risk Agent Actions · https://datatracker.ietf.org/doc/draft-schrock-ae-challenge/（A级）