缩小权限时撤销旧的宽泛授权

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

audit-bot原令牌有读写权，任务改为只读。只另发窄令牌会留下旧宽令牌可写；收窄同一主体需撤销旧会话。

具体做法

核主体稳定身份及当前全部有效授权，使用宿主支持的同主体收窄/撤销机制，明确生效时点和重连要求。签发/激活窄授权并验证旧凭据拒绝、新读允许、新写拒绝；涵盖通用JS和别名路线。轮换顺序按实际服务确保不留宽权限窗口，保留审计不输出凭据。

反例

给audit-bot发新只读token，但旧写token仍有效；换主体名称认为等于收权。

改进写法

同一audit-bot主体收窄到read，撤销旧宽会话并按服务契约重连新授权。用受控读取/写入探测，新读通过、新写与旧凭据拒绝；记录实际范围、生效时间及未覆盖授权。

为什么这样改

多个令牌可能并存，新增窄权不减已有宽权。主体绑定撤销才使实际可达能力收窄，而不是只有新配置看起来安全。

如何验证

教学旧令牌仍能写则收窄失败，无论新令牌叫什么。旧拒、新读可、新写拒才支持所测范围；改新主体却留原主体有效也不满足。凭据只用安全标识记录。

适用边界

提示不能撤服务端权，缓存、在途请求及其他会话可能延迟或扩展范围。来源配对特性是冻结产品行为，移用需核实际运行时；只读命令名不排除JS副作用。