MCP 远程服务器授权为什么必须带 resource：OAuth 2.1 受众绑定的最小实现

先给结论：resource 不是可有可无的备注，而是“这枚 token 准备给谁用”的明确边界。远程 HTTP MCP 客户端应该为目标 MCP endpoint 固定一个 canonical URI，把它同时放进授权请求和 token 请求；MCP 服务端收到 Bearer token 后，还要确认 token 的受众就是自己。只把上游 token 原样透传给下游，会把跨服务器误用变成默认行为。

本文只讨论 OAuth 2.1 风格的 HTTP MCP 授权，不展开 STDIO 凭据、具体身份供应商或完整客户端注册界面。下面的“最小实现”重点是参数在哪里出现、服务端最后检查什么。

resource 要先绑定到哪个 MCP 服务器

先把实际 MCP 地址当成资源身份，而不是把授权服务器地址当成资源身份。例如客户端访问 https://mcp.example.com/server/mcp，就可以把这个最具体的绝对 URI 作为 resource。它不能缺少 scheme，不能带 fragment；项目还应统一是否保留尾部斜杠，避免同一服务出现两个字符串身份。

当 MCP 返回 401 时，客户端应解析 WWW-Authenticate 中的 resource_metadata，或按规范尝试 .well-known/oauth-protected-resource。元数据告诉客户端对应的 authorization_servers，但不改变 resource 的指向：resource 仍然是要调用的 MCP 服务器。

授权请求和令牌请求要用同一个值

拿到授权端点后，授权码请求至少要保持三件事一致：client_id、PKCE 的 code_challenge，以及目标 MCP 的 resource。示例中的 URI 只是演示结构，生产环境应从实际 endpoint 配置生成：

const resource = "https://mcp.example.com/server/mcp";
const authorize = new URL("https://login.example.com/oauth/authorize");
authorize.search = new URLSearchParams({
  response_type: "code",
  client_id,
  redirect_uri,
  code_challenge,
  code_challenge_method: "S256",
  resource,
  scope: "files:read"
});

用户同意后交换 code 时不要把 resource 丢掉。令牌请求再次携带同一个值，并用原来的 verifier 完成 PKCE 交换：

const token = await fetch(token_endpoint, {
  method: "POST",
  headers: { "content-type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({
    grant_type: "authorization_code",
    code,
    client_id,
    redirect_uri,
    code_verifier,
    resource
  })
});

关键不是某个 SDK 是否自动补参，而是授权请求和 token 请求的 resource 必须指向同一个 MCP 资源。调用阶段把 token 放在 Authorization: Bearer ... 请求头中，不要放在 URL 查询串；同一逻辑会话中的每个 HTTP 请求也都要带授权头。

服务端为什么必须再验一次 audience

客户端带上 resource，只完成了“请求令牌时声明目标”的一半工作。MCP 服务端仍是 OAuth resource server，必须验证签名、过期时间、issuer，以及 token 是否为自己签发或明确以自己为 audience。scope 只表示权限范围，不能替代 audience；issuer 可信，也不代表这枚 token 可以访问所有 MCP 服务器。

伪代码可以压缩成一个明确的拒绝点：

claims = verify_access_token(token)
if claims.issuer not in trusted_issuers:
    return 401
if resource not in claims.audience:
    return 401
if not required_scope.issubset(claims.scope):
    return 403
return handle_mcp_request()

这里的状态码也有边界：token 缺失、无效、过期或受众不匹配，返回 401；身份有效但权限不足，返回 403，并可在 WWW-Authenticate 中提示所需 scope。不要因为网关已经验过 token，就让 MCP 层接受任意上游 Bearer token，更不能替下游服务器转发没有为它签发的 token。

上线前用四个问题收口

第一，resource 是否来自真实 MCP endpoint，而不是登录域名？第二，授权请求和 token 请求是否使用完全一致的值？第三，服务端是否把 audience 当成独立检查，而不是只检查 scope？第四，缓存、日志和错误重试是否会把 token 带到另一个 MCP host？这四问能覆盖最常见的“能登录但调用被拒绝”和“误把 A 服务 token 发给 B 服务”两类问题。

小结：发现授权服务器解决“去哪里拿 token”，resource 解决“token 给谁用”，audience 校验解决“收到后是否真的属于我”。三层职责分开，远程 MCP 的 OAuth 链路才不会退化成无边界的 token 透传。

相关问题

resource 可以写成授权服务器地址吗？不应这样做。它应标识要访问的 MCP 资源；授权服务器只是发行 token 的角色。

scope 足够细时还需要 audience 吗？需要。scope 表达权限，audience 表达目标资源，两者不能互相替代。