MCP联邦凭据双边界：Envoy逐后端转发与OAuth issuer绑定

wiki/ai/sources/envoy-mcp-header-policy-and-oauth-issuer-binding.md

分类：ai / sources · 更新：2026-10-28 09:18

MCP联邦凭据双边界：Envoy逐后端转发与OAuth issuer绑定

知识点轴：MCP Gateway / sandbox-security / harness-runtime / benchmark-evaluation。结论：允许连接一个工具服务器，不代表允许把已有凭据交给它；网关转发策略和OAuth发现策略必须各守自己的接收方边界。

为什么值得深挖

Hermes接多MCP后端、网关联邦和自动发现时，会遇到两个不同的凭据流：客户端→网关→工具后端的HTTP header，以及客户端→授权服务器token endpoint的OAuth材料。两者都不能靠“此连接已认证”替另一个接收方作授权决定。与unla-oauth-token-validity-versus-resource-authorization的可信授权根/目标资源双门互补：这里追问的是哪个接收方有权取得这份凭据，不是只验证token有效性。

这不是今日零日速报：Envoy变更PR #46818于2026-10-05合并，1.40.0发布页标2026-10-13；Python公告GHSA-qx49-fqc8-xw99 / CVE-2026-115563发表于09-28、10-23更新。本轮价值是把固定实现和修复后的残余配置条件合成可复用验收合同。^[raw/articles/envoy-140-backend-header-forwarding-pinned-2026-10-28.md] ^[raw/articles/mcp-python-oauth-issuer-credential-binding-advisory-2026-10-28.md]

机制一：逐后端header准入不等于凭据换发

Envoy v1.40.0对应commit 9e5580933739775e8bce696a57a2e1bc99368f23。McpRouter.McpBackend和mcp_multicluster.ClusterConfig.McpBackend两套配置均有header_forwarding。未配置时，除路由器自行合成的必需header外，不转发下游控制的header，尤其不默认转发authorization。旧版本的广泛转发行为可被显式forward_all: true恢复；这也是升级后为了“修好认证”而重新扩大泄漏面的风险点。^[raw/articles/envoy-140-backend-header-forwarding-pinned-2026-10-28.md]

固定源码给出的次序是：

路由器先跳过自己拥有的协议/framing/session/header及hop-by-hop集合；此层不是用户allowlist能覆盖的。
对其余header，disallowed_headers命中则拒绝。
否则forward_all为真则允许；再否则看allowed_headers；均不命中则拒绝。

因此deny > forward_all / allow，但不能把第二层匹配器单独称为完整安全策略。createUpstreamHeaders先构造method/path/host、JSON content-type、JSON/SSE accept及backend session，再调用复制函数。HTTP头转发不负责token exchange、audience绑定、credential injection或tool级授权；安全默认关闭的是一条隐式传播通路，不是完成了OAuth联邦。^[raw/articles/envoy-140-backend-header-forwarding-pinned-2026-10-28.md]

上游测试源码包含默认不转发、显式全转发、allow-only、deny覆盖全转发及proxy-authorization永不转发，并参数化两种配置源。这里只是读过这些测试，不声称本机执行通过，更不证明用户部署采用这些有效配置。

机制二：发现的issuer与已有credential归属分别核验

Python SDK公告描述两个缺口：授权服务器metadata的issuer没有在每条发现路径验证；已有/预置client credentials没有绑定所属授权服务器。不可信MCP服务可利用它声明的授权服务器或legacy fallback，让client把本应给真实授权服务器的secret、code、PKCE verifier或签名assertion送往错误token endpoint。PKCE防截获不等于token endpoint接收方可信。^[raw/articles/mcp-python-oauth-issuer-credential-binding-advisory-2026-10-28.md]

公告正文列1.9.1—1.29.1与2.0.0—2.1.1的受影响路径；API版本范围还包含2.0.0a1起的预发布版，不应把正文稳定版列举误作排除预发布版。修复线为1.30.0 / 2.2.0及以后。对client-credentials和private-key JWT provider，升级还必须显式设置issuer=；省略仍跟随server广告的授权服务器，只新增弃用告警。1.30.0的DeprecationWarning可能默认不可见，不能依赖日志告警作为强制边界。^[raw/articles/mcp-python-oauth-issuer-credential-binding-advisory-2026-10-28.md]

旧存储注册没有issuer时不会自动变成已绑定：公告建议清除旧client registration重注册，或给自己预置的注册记录补正确issuer；若过去可能连接不可信server，再按暴露范围轮换secret/撤销token。这里只记录官方条件建议，没有检查或更改用户凭据/SDK/存储。公告不把stdio、SDK server或自行附token/header的client列为此次漏洞受影响对象；这不等于它们没有其他透传风险。

对Hermes / 网关工作流的可执行启发

参考MCP-Gateway-Runtime与Harness-Engineering，在获准的隔离环境建立小型可信/不可信后端fixture：

验收对象	负例	正例 / 必须同时成立的效用
每个MCP backend的最终请求	默认配置不出现客户端Bearer/cookie；deny与allow重叠时仍拒绝	只放行所需trace字段，工具调用仍可用
明确配置全转发的兼容例外	标出受众/后端trust，不用全局开关修所有后端	后端自有凭据独立注入且可撤销
metadata发现路径	advertised AS、无PRM fallback、403 insufficient_scope分别测错issuer	正确issuer能完成合法OAuth
credential存储	issuer A注册不得被issuer B复用	明确绑定后同issuer正常续用
观测与审计	不把secret/code/verifier写trace	仅记接收方身份、配置版本、拒绝原因及零错误投递

这张表是验收设计，不是已运行结果。应在实际出站接收端检查header/材料，而非只看配置JSON或客户端“认证成功”。不向公网第三方发测试secret，不为这次入库重启gateway。

边界与未解问题

Envoy header治理和Python SDK客户端发现是两个独立产品/边界；不能推断部署了Envoy就修复SDK，或升级SDK就隔离后端Bearer。
issuer、token的aud、服务/工具授权、请求实际dial目标分别有独立语义。issuer验证不替代contextforge-egress-path-parity-dns-rebinding的连接时目标约束。
读release、固定源码与测试不是编译/端到端证明；未核用户环境、实际授权服务器、缓存迁移和生产请求。
后续优先补三条发现路径与双issuer旧注册的合法/非法成对实测，而不是再造一个泛化“零信任网关”薄概念页。

写入记录

2026-10-28 09:13 CST：基于Envoy固定发布源码/测试与Python SDK官方公告，新增逐backend header准入、issuer/旧注册绑定和分路径验收；明确旧事件与本轮新综合、无本机PoC/部署证据。