用验收测试检查代理令牌能否被盗用

校验通过的 access token，只能说明令牌有效，未必能证明拿着它发请求的，就是最初获得令牌的工作负载。原文围绕一个虚构的供应商记录连接器，设计了一套验收测试：令牌被复制后，攻击者能否直接调用接口？

作者的结论很明确：发送方约束可以限制被盗令牌的使用，但业务权限、重复执行、签名能力失陷仍需分别处理。这不是生产实现或性能实测，而是一份帮助团队划清安全边界的测试设计。

令牌有效，为什么还要证明是谁在使用

原文设定的调用链是连接器到网关，再到供应商 API。连接器从授权服务器获取令牌，读取供应商资料和修改资料使用不同权限。网关对外开放，API 的内部监听入口不应成为绕过网关的通道。

攻击者最初只能复制 access token，不能提取工作负载的私钥，也不能调用它的签名能力。因此，第一项验收目标很具体：把令牌复制到一个独立客户端，不能仅凭它访问受保护资源。

发送方约束（sender constraint）就是让资源服务器进一步核对：请求者是否持有与令牌绑定的密钥或证书。普通令牌校验、最小权限和资源级授权依然需要保留。

能证明请求来自合法持有者，不等于这个请求应该被允许。

例如，一个只获准读取资料的连接器，即便提交了有效的持有证明，也不能修改供应商记录。测试必须把这两层判断拆开，否则一个笼统的「请求失败」无法说明究竟是哪项控制起了作用。

DPoP 和 mTLS 分别在核对什么

RFC 9449 定义的 DPoP，要求客户端随请求提供签名证明。验证范围包括签名、允许的算法、必需声明、HTTP 方法、目标 URI 和时效条件。访问受保护资源时，证明还需要包含 access token 的哈希，证明使用的公钥也必须与令牌绑定一致。

这里有两个容易误解的边界。目标 URI 的比较不包含查询参数和片段；基础 DPoP 证明也不覆盖请求体。因此，不能把 DPoP 描述成「给采购订单签了名」，更不能据此认定订单里的每个业务字段都经过批准。TLS 仍然必需，交易级审批和完整性需要另行设计。

DPoP 本身也不是 OAuth 客户端认证。机密客户端可以同时使用适当的客户端认证方式，两类检查应在代码和监控中分开。

如果部署使用服务端 nonce，还要验证挑战与接受流程。授权服务器和资源服务器的 nonce 不能混用。时钟容差、重复证明在多个副本间的处理同样需要测试：单个进程能拦住重放，不代表另一个实例也能识别。

RFC 8705 则定义了 OAuth mutual-TLS 客户端认证和证书绑定 access token。对于后者，资源服务器需要核对令牌绑定与当前 mTLS 连接使用的证书是否匹配。发令牌时认证过客户端，与访问资源时确认令牌绑定，是两项独立能力。

如果 TLS 在网关终止，API 如何可信地获得验证结果，就成为部署设计的一部分。客户端能自行填写的「证书信息」请求头不能作为依据，内部信任边界、请求头处理和旁路入口都要验收。

证书轮换也不能只看工作负载名称是否相同。旧证书绑定的令牌，不会因为换了新证书就自动可用；恢复流程必须包含受支持的令牌签发与过渡方案。

验收测试要分清哪一层拒绝了请求

先建立基线：合法客户端使用有效令牌和正确证明，请求应到达业务策略判断。随后分别测试只复制令牌、使用错误签名密钥、使用不匹配证书，预期都在发送方约束这一层被拒绝。

对于 DPoP，还要逐项改变 HTTP 方法、目标 URI、令牌哈希，测试超出接受时间窗口以及部署约定的重放处理。对于 mTLS，则要覆盖真实的客户端到执行组件的连接，以及经过代理的路径。TLS 握手成功只是中间结果，最终仍要确认资源会拒绝证书绑定不匹配的令牌。

还应单独测试「证明正确但业务权限不足」：只读连接器尝试修改供应商记录，发送方检查可以通过，业务策略应拒绝。报告需要记录预期决定、实际决定和执行组件，并用安全的关联标识串起证据，不能记录私钥或原始令牌。

重试也有独立边界。证明标识与业务操作标识用途不同，重试生成了新的证明，不代表同一业务操作可以执行两次。幂等性仍由应用负责。

最后，主动改变攻击假设：让攻击者能够使用合法私钥，或者调用缺少限制的签名服务。此时令牌绑定无法区分攻击者与合法持有者，需要依靠工作负载隔离、签名服务访问控制和凭证恢复处理。

证明生成或验证不可用时，也要提前约定行为。原文选择暂缓敏感修改，不通过仅携带 bearer token 的路径重试。这是示例策略，并非普遍标准；只读操作若采用不同可用性策略，也需要明确负责人和风险范围。

我的判断

这套设计最有价值的地方，是把「令牌有效」「持有证明有效」「业务操作获准」拆成可分别验证的结果。对接 agent connector 时，这比只统计成功率或失败率更能定位问题。

但原文没有生产实现、基准测试或对照数据，无法据此判断 DPoP 与 mTLS 哪种成本更低、延迟更小，也不能确认某个技术栈已经完整支持。它提供的是验收思路，具体部署仍要使用维护中的实现，并按完整标准核对。

与普通 bearer token 相比，发送方约束针对的是令牌被复制后的滥用，前提是密钥和签名能力仍受到保护。如果攻击者能让合法工作负载代为签名，这个前提就不成立了。

通过这套测试，只能证明凭证使用受到约束，不能证明 agent 的行为安全。

它没有验证提示注入防护，也没有证明权限分配合理或交易结果正确。这个范围应当直接写进验收结论，避免团队把局部通过理解成整体安全。

能拿来做什么

• 给 Node 连接器或 API 网关设计验收用例时，先加入合法请求、复制令牌、错误密钥或证书、有效证明下的越权操作，并分别标明预期拒绝位置。
• 对经过反向代理的服务，检查 TLS 终止位置、验证结果传递方式、请求头处理和内部直连入口，把真实部署路径纳入测试。
• 为有重试机制的修改接口单独检查幂等性，确保新生成的 DPoP 证明不会被当成重复执行同一业务操作的许可。
• 在接入 agent 工具前，明确证明服务故障时敏感操作如何处理，并让审计记录能关联工作负载、策略版本和执行组件，同时避开原始凭证。