面试题库

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

D6 安全与治理：工具描述里的提示注入、混淆代理、最小权限、审计日志与工具白名单

• 混淆代理攻击在 MCP 场景里具体是怎么发生的？规范要求怎么防？How does the confused deputy attack play out in an MCP setting, and what does the spec require to prevent it?

  国内高频海外高频深入#oauth#confused-deputy

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

  1. 这题在筛 OAuth 的实战经验。能背出「混淆代理就是代理被骗着用自己的权限做事」只算入门，面试官要的是这条链在 MCP 里的具体形状。
  2. 先把角色摆清：出事的是**代理型服务端**——它对 MCP 客户端是服务端，对第三方 API 是一个 OAuth 客户端。它自己不是被攻破的那个，它是被利用的那个。
  3. 然后列四个必须同时成立的条件，少一个就打不成：代理对第三方用**静态 client id**（所有用户共用一个）；代理允许 MCP 客户端**动态注册**，各自拿到自己的 client id；第三方授权服务器在用户首次同意后**设了同意 cookie**；代理在转给第三方之前**没有做按客户端的同意确认**。
  4. 再串攻击链：攻击者先向代理动态注册一个客户端，redirect_uri 填自己的地址；把构造好的授权链接发给用户；用户浏览器带着上次留下的同意 cookie 去第三方，第三方认出静态 client id 加 cookie，**跳过同意页**直接发授权码；授权码回到代理，代理换成 MCP 授权码，按注册时那个恶意 redirect_uri 回跳，码落到攻击者手里；攻击者拿它换令牌，冒充用户访问。**整条链上用户什么都没同意过**——那个 cookie 是他上次正常授权时留下的。
  5. 防法要按规范的措辞答：代理型服务端**必须**实现按客户端的同意，而且这次同意必须发生在**转给第三方之前**。配套四条：同意记录按「用户加 client id」存，不是只记「这个用户同意过」；redirect_uri 精确字符串匹配、不做通配、改了就要重新注册；state 用安全随机数、单次使用、短过期，并且**同意通过之后才落 cookie 或会话**（提前落等于同意页形同虚设）；同意页要有 CSRF 防护并禁止被 iframe 内嵌。
  6. 可预期的追问一：这和令牌转发什么关系？令牌转发是受众校验失败的下游后果，混淆代理是同意确认缺失造成的授权码劫持，根子都是「服务端替别人做了决定却没确认这个别人是谁」。追问二：我怎么知道自己要不要管这一节？判据一句话——我的服务端有没有替用户去第三方要过授权。没有就整节不适用，有就是必须做。

  How to reason about it · think before answering

  1. This screens for hands-on OAuth. Reciting 'a deputy tricked into using its own authority' is entry level; the interviewer wants the concrete chain as it appears in MCP.
  2. Fix the roles first: the vulnerable party is a proxy server, which is a server to the MCP client and an OAuth client to the third-party API. It is not compromised, it is used.
  3. List the four conditions that must all hold: the proxy uses a static client id with the third party; the proxy lets MCP clients register dynamically, each with its own client id; the third-party authorization server sets a consent cookie after the first approval; and the proxy performs no per-client consent before forwarding.
  4. Then the chain: the attacker dynamically registers a client with their own redirect_uri, sends the user a crafted authorization link, the browser carries the old consent cookie to the third party, which recognizes the static client id plus cookie and skips the consent screen, the code returns to the proxy, the proxy mints an MCP authorization code and redirects to the attacker's registered URI, and the attacker exchanges it for tokens. The user consented to nothing in this flow; the cookie came from a legitimate earlier one.
  5. Answer the mitigation in the spec's own terms: proxy servers MUST implement per-client consent, and that consent must happen before forwarding to the third party. Four supporting requirements: store consent keyed by user plus client_id rather than 'this user consented'; match redirect_uri by exact string with no wildcards and require re-registration on change; make state cryptographically random, single use, short lived, and set its cookie or session only after consent is approved, since setting it earlier renders the consent screen ineffective; and protect the consent page with CSRF defenses and frame-ancestors or X-Frame-Options.
  6. Likely follow-ups: how does this relate to token passthrough? Passthrough is the downstream consequence of failed audience validation, while the confused deputy is code hijacking from missing consent; both stem from a server deciding on someone's behalf without confirming who that someone is. And how do I know whether this applies? One test: has my server ever obtained third-party authorization on a user's behalf.

  答题要点

  • 受害者是代理型服务端：对客户端是服务端，对第三方是一个 OAuth 客户端
  • 四个条件同时成立才打得成：静态 client id、允许动态注册、第三方有同意 cookie、缺少按客户端的同意
  • 攻击链的关键一步是第三方认出 cookie 跳过同意页，授权码按恶意 redirect_uri 落到攻击者手里
  • 必须在转给第三方之前做按客户端的同意；redirect_uri 精确匹配；state 单次短过期且同意后才落

  Key points

  • The victim is a proxy server: a server to the MCP client, an OAuth client to the third party
  • Four conditions must coincide: static client id, dynamic registration, a third-party consent cookie, and no per-client consent
  • The pivot is the third party skipping consent on the cookie, sending the code to the attacker's redirect_uri
  • Per-client consent must precede forwarding; redirect_uri matched exactly; state single use, short lived, and stored only after approval