面试题库

7 天 MCP：把工具接进任何 Agent

D4 远程 MCP：Streamable HTTP 绑定、无状态模型与请求元数据、OAuth 2.1 授权、容器部署

• 为什么 MCP 服务端绝对不能把客户端给的访问令牌直接转发给下游 API？Why must an MCP server never forward the client's access token straight to a downstream API?

  国内高频海外高频深入#oauth#security

  分析过程 · 先想清楚再作答

  1. 这题在考安全边界的直觉。答「不安全」「会泄露」是空话；规范给这个反模式起了名字叫令牌转发（token passthrough），并明令禁止，能说出它坏在哪三处才算过关。
  2. 先把前提说清：MCP 服务端在授权体系里是 OAuth 2.1 的资源服务器，它必须校验收到的令牌受众就是自己（客户端靠 RFC 8707 的 resource 参数让授权服务器把受众写进令牌），并且必须只接受对自己资源有效的令牌，不得接受或转接其它令牌。
  3. 拆危害的角度是「谁的假设被打破了」。第一，绕过安全控制：限流、请求校验、流量监控往往挂在「这个令牌是发给我的」这个前提上，客户端拿着别处的令牌直连或经服务端转发，这些控制全空转。第二，审计链断裂：服务端分不清是哪个客户端在调（上游令牌对它可能是不透明的），下游日志里的身份又不是真正在转发的那个服务端，出事之后没人能还原现场；持有失窃令牌的人还能把服务端当成数据外泄的代理。第三，信任边界被打穿：下游是按「只有上游那个服务能拿到这个令牌」授信的，一旦某个服务被攻破，同一个令牌就能横着走。
  4. 结论：服务端要访问下游，就得自己作为 OAuth 客户端去拿一份属于自己的凭证，和客户端给自己的令牌完全隔离。
  5. 正确做法要一起说：需要代表用户访问第三方时走 URL 模式的补充输入，让用户在浏览器里直接和第三方完成授权，服务端把第三方令牌存在自己这边并绑定到已认证的用户身份。规范要求第三方凭证不得经由 MCP 客户端传输。
  6. 可预期的追问：那和混淆代理是什么关系？令牌转发是受众校验失败的下游后果，混淆代理是代理型服务端用静态 client id 加上跳过按客户端的同意确认造成的授权码劫持——两者都源于「服务端替别人做决定却没确认这个别人是谁」。这一条第 6 天会展开。

  How to reason about it · think before answering

  1. This probes your instinct for trust boundaries. 'It is insecure' is empty; the spec names this anti-pattern token passthrough and forbids it, so you need the three concrete failure modes.
  2. Set up the premise: in the authorization model an MCP server is an OAuth 2.1 resource server. It must validate that tokens were issued with itself as the audience — clients make that possible via the RFC 8707 resource parameter — and must accept only tokens valid for its own resources, accepting or transiting nothing else.
  3. Derive the harm by asking whose assumption breaks. First, security controls are circumvented: rate limiting, request validation, and traffic monitoring hang off 'this token was issued to me', and a token minted elsewhere makes them no-ops. Second, the audit trail breaks: the server cannot distinguish clients when the upstream token is opaque to it, downstream logs show an identity that is not the forwarding server, and a thief of a stolen token can use the server as an exfiltration proxy. Third, the trust boundary is punctured: downstream grants trust on the assumption that only the upstream service holds the token, so one compromise travels sideways.
  4. Conclusion: to call downstream, the server must obtain its own credential as an OAuth client, fully isolated from the token the client presented to it.
  5. Give the correct pattern too: for third-party access on the user's behalf, use URL-mode elicitation so the user authorizes the third party directly in a browser, and the server stores those tokens bound to the authenticated user identity. The spec requires third-party credentials never to transit the MCP client.
  6. Likely follow-up: how does this relate to the confused deputy? Token passthrough is the downstream consequence of failed audience validation, while the confused deputy is authorization-code hijacking caused by a proxy server combining a static client id with skipped per-client consent. Both come from a server acting for someone without confirming who that someone is.

  答题要点

  • MCP 服务端是 OAuth 2.1 资源服务器，必须校验令牌受众是自己，不得接受或转接其它令牌
  • 转发会绕过挂在受众上的限流、请求校验与流量监控
  • 审计链断裂：服务端分不清调用方，下游看到的身份也不是真正的转发者，还可能被当成外泄代理
  • 正确做法是服务端自己作为 OAuth 客户端取下游凭证，第三方凭证绝不经由 MCP 客户端

  Key points

  • An MCP server is an OAuth 2.1 resource server: it must validate that it is the token audience and must not accept or transit other tokens
  • Forwarding bypasses rate limiting, request validation, and monitoring that assume audience-bound tokens
  • The audit trail breaks: the server cannot identify callers, downstream sees the wrong identity, and the server can become an exfiltration proxy
  • The correct pattern is for the server to obtain its own downstream credential as an OAuth client, with third-party credentials never transiting the MCP client