MCP Server 如何代表用户调用你的 API：生产级 token 策略实践

在上一篇文章里，我们分享了 Logto 落地 Remote MCP Server 的整体经验, 这篇文章我们将讲解 Remote MCP Server 架构设计和 OAuth 认证流程的实现细节。

以 MCP Server 为分界，Remote MCP Server 的认证分**入站（inbound）和出站（outbound）**两段：

• 入站：MCP client（VS Code、Cursor 等）通过 OAuth 登录，拿到 access token，用它访问你的 MCP Server
• 出站：MCP Server 处理 tool 调用时，代表用户去请求你自己的业务 API

入站这部分，MCP 规范定义得很清楚，社区的讨论和实践也很充分，我们之前写过一篇实现指南。出站的讨论就少多了：MCP Server 手里只有一张「用于访问 MCP Server」的 token，它要如何代表用户去调用业务 API？

这正是我们在落地 Logto MCP Server 时反复纠结的问题。Logto Cloud 是典型的 B2B 多租户产品：一个用户可以属于多个 tenant，权限由用户在每个 tenant 里的角色决定，AI 不仅要代表用户行事，还要落到正确的 tenant。

这篇文章会沿着我们实际的决策过程展开：

• 为什么 MCP Server 要独立部署，并作为独立的 protected resource
• 两个被我们否决的出站方案（token 透传、M2M token）以及它们的问题
• 最终方案 token exchange + subject token 的完整链路，包括多租户场景下 organization token 的处理
• 做同类设计时需要守住的几条原则

问题的本质：MCP Server 的双重身份#

在 OAuth 的视角里，Remote MCP Server 同时扮演两个角色：

• 对 MCP client，它是 resource server：client 必须带着 token 来访问它
• 对业务 API，它是 client：它要带着 token 去访问别人

也就是说，MCP Server 在两侧扮演不同的角色，各自对应的是不同的 token：MCP client 通过 OAuth 拿到的 token，audience 是 MCP Server，业务 API 校验 audience 时会直接拒绝它。

所以出站的本质是一个身份委托（delegation）问题：MCP Server 如何在不持有用户凭证的前提下，以用户的身份、在用户的权限范围内调用下游 API。

架构决策：MCP Server 作为独立服务#

把 MCP endpoint 做进业务 API 服务，共用同一个进程、同一套认证，看起来是最直接的做法。但经过考量，我们还是选择了独立部署：

• 风险隔离：做决策时 MCP 官方 SDK 离 production ready 还有距离，协议本身也在快速演进（transport 从 SSE 到 Streamable HTTP 的切换就是例子）。Logto 是 IAM 服务，登录主链路的可用性是底线。独立部署下，MCP Server 出问题最多是 AI 入口不可用，主服务不受影响。
• 独立迭代：MCP 生态的变化以周计，客户端兼容性问题随时需要热修；核心服务有严格的发布流程和回归验证。分开部署，两边互不拖累。
• 运行时自由：独立服务可以挑最适合自己的运行时。Logto MCP Server 跑在 Cloudflare Workers 上，无状态、按请求伸缩、几乎零运维；内嵌方案里没有这个选项。

MCP Server 部署在独立的域名 mcp.logto.io 下，和主服务之间没有任何私有耦合，未来想把它开源出去都没有障碍。

内嵌方案也绕不开 token 问题：MCP endpoint 和业务 API 共享同一个 resource identifier，MCP client 拿到的 token 直接携带全量 API 的权限；「这次调用以谁的权限执行」从跨服务的 token 交换变成进程内的权限传递，问题本身还在。独立部署要求我们把权限边界显式设计出来，这也是这篇文章接下来的内容。

MCP Server 必须有自己的 resource identifier#

出站的讨论要从一个更基础的问题开始：MCP client 拿到的 token，audience 应该是谁？

直接复用业务 API 的 resource identifier 是最直接的做法：Logto 的 Management API 本身就是标准的 OAuth protected resource，让 MCP client 直接申请它的 token，MCP Server 原样转发。不少 MCP Server 的早期实践就是这么做的。

代价在于：如果 MCP token 的 audience 是业务 API，权限边界就不存在了。

• 你精心设计的 MCP tools 形同虚设：token 本身就能调全量 API，不需要经过你的 tools
• Token 泄漏的爆炸半径，从「MCP Server 暴露的几个受控操作」扩大到「整个 Management API」
• MCP 场景的独立审计、限流、权限收敛，都无从做起

所以我们的第一个决定是：MCP Server 是一个独立的 protected resource，有自己的 resource identifier（https://mcp.logto.io）和对应的 scope。

这个决定让权限边界干净了，出站的问题也随之变得具体：token 只能访问 MCP Server，那 MCP Server 拿什么去调 API？

下面进入方案演进。

方案一：token 透传#

第一个想法来自一个很自然的类比。

Logto Console 是一个 SPA，它调用 Management API 的方式很简单：用户在浏览器里 OAuth 登录，拿到 audience 为 Management API 的 token，前端直接带着它调 API。

那 MCP Server 是不是也可以当作另一种 Console？让 MCP client 在登录时直接申请业务 API 的 token，MCP Server 不做任何转换，原样转发：

这个方案的诱人之处就在于它极其简单，MCP Server 只负责转发 token。但是它有显而易见的问题：

第一，它和上一节的权限边界决定直接冲突。 Token 透传要求 MCP client 持有业务 API 的 token，这正是我们刚刚否决掉的事情。

第二，MCP Server 不再是真正的 protected resource。 它收到的 token audience 不是自己，audience 校验形同虚设，只能退化成「验证签名和 issuer」。这不符合 MCP 规范对 authorization 的定义（MCP Server 应作为 resource server，通过 RFC 9728 的 Protected Resource Metadata 声明自己），本质上是把一个后端服务伪装成了浏览器里的 SPA。

第三，MCP client 不配合。 规范的 MCP client 按 Protected Resource Metadata 的指引申请 token，audience 就是 MCP Server。没有标准的方式让它去申请业务 API 的 token，这条路在客户端侧走不通。

方案二：M2M token#

既然不能用用户的 token，那用 MCP Server 自己的身份呢？

给 MCP Server 配一个 M2M（machine-to-machine）应用，用 client credentials 拿 token，去调业务 API。这也是很多内部服务之间的标准做法。

入站认证也顺了：MCP client 的 token audience 是 MCP Server，MCP Server 正常校验，然后用自己的 M2M token 干活。

这个方案的致命缺陷是，M2M token 的权限和用户的权限没有任何关系：

• 权限越界：M2M token 的权限是「MCP Server 能做什么」，不是「这个用户能做什么」。一个只读角色的用户，通过 MCP 却能删除应用，因为 M2M token 有这个权限
• 身份丢失：下游 API 看到的调用者永远是那个 M2M 应用，审计日志对不到具体的人
• 混淆代理人问题（confused deputy）：MCP Server 成了一个高权限代理，任何能说服它发起调用的人，都借到了它的权限

M2M 适合定时任务、系统间同步这类没有用户上下文的场景。MCP Server 不一样，每次调用都由具体的用户发起，就应该以这个用户的身份和权限去执行。

最终方案：token exchange + subject token#

前两个方案的教训汇总起来，就是理想方案的要求：

1. MCP client 手里的 token 只能访问 MCP Server（方案一的教训）
2. MCP Server 调下游 API 时，必须以用户身份、在用户权限范围内（方案二的教训）

这指向一个标准机制：token exchange（RFC 8693）。MCP Server 拿一张代表用户的凭证去 auth server 交换下游 API 的 token，用户的身份和权限在交换中保留。

在 Logto 里，这张「代表用户的凭证」由 user impersonation 能力提供：subject token。它是服务端为指定用户申请的短期凭证，语义是「接下来这次 token exchange，以这个用户的身份进行」。用户不需要手动创建或配置任何东西，全程自动化；subject token 短期、一次性，用完即失效。

整个架构里有四个角色，MCP Server 独立部署在 mcp.logto.io：

一次 tool 调用背后的完整 token 流转：

逐步拆解：

① 入站验证。MCP client 带着 user token 调用 tool。这个 token 的 audience 是 MCP Server 自己的 resource identifier，scope 是 mcp:all。MCP Server 校验签名、issuer、audience、scope，拿到用户身份。入站到此为止，这个 token 不会再往下游走。

② 服务身份认证。MCP Server 用自己的 M2M 凭证换一个 access token，scope 是专设的 access:mcp:api，它只有一个用途：调用下一步的专用接口。

③ 申请 subject token，整条链路的关键一步。MCP Server 调用 Cloud 专门为 MCP 开的接口 POST /api/mcp/subject-tokens，同时出示两个凭证：

• Authorization 头：M2M token，证明「我是官方 MCP Server」
• x-mcp-user-token 头：用户的 user token，证明「这个用户确实授权过我，且授权仍然有效」

Cloud 这边会对 user token 做完整校验：签名、issuer、有效期，audience 必须是 MCP Server 的 resource identifier，scope 必须包含 mcp:all。校验通过后，userId 直接取自 user token 的 sub claim，接口没有「指定用户」的参数。

这样设计是为了防止 M2M 凭证被滥用：如果接口接受任意 userId，拿到 M2M 凭证就能冒充任何用户；在这个设计下，MCP Server 只有在某个用户的有效授权在场时，才能为这个用户兑换凭证。

签发出来的 subject token 短期、一次性，实现里不做缓存，每次使用都现场申请。

④ 换出干活的 token。拿 subject token 走标准 token exchange，按需换两种 token：

• Cloud API token：以用户身份做用户级操作，比如列出 tenant、创建 tenant
• org token：指定目标 tenant（Logto Cloud 里每个 tenant 对应一个 organization），换到的 token 以用户身份签发，权限严格等于用户在该 tenant 里的角色

⑤ 出站调用。带着换来的 token 调用业务 API，做完事把结果返回给 MCP client。

多租户的 tenant 上下文也在交换这一步解决：tenant 不在连接层，而在交换层。list_tenants 用 Cloud API token 列出选项，用户在对话里选一个，MCP Server 再为选中的 tenant 换 org token。一个 endpoint 服务所有 tenant，不需要为每个 tenant 单独部署，对话中途新建的 tenant 也即刻可用。

为什么说这套链路是对的#

把前面每个方案的失败点拿回来对照，会发现它们都被逐一堵上了：

• user token 的爆炸半径受控（方案一的教训）：它的 audience 只有 MCP Server，泄漏了也只能调那几个受控的 tools
• M2M 无法被滥用（方案二的教训）：M2M token 不再直接调业务 API，只用来证明服务身份。签发 subject token 时必须同时出示该用户的有效 user token，MCP Server 只能为授权过它的用户换取凭证，confused deputy 问题就不存在了
• 没有任何用户凭证需要保管：subject token 现场申请、用完即弃，MCP Server 除了自己的 M2M 凭证，不存任何东西
• 撤销是联动的：用户撤销对 MCP 的授权，user token 随之失效，x-mcp-user-token 验证失败，出站链路当场断掉
• 权限对齐用户本人：换出的 token 以用户身份签发，只读用户通过 MCP 还是只读，越权在 auth server 层面就不成立；审计日志里看到的也是真实的用户身份

回头看，M2M 在最终方案里有了正确的分工：它负责证明「我是谁」，而「以用户身份行事」的资格，必须由用户的有效授权当场兑换。

结语#

回顾整条链路，Remote MCP Server 的 token 策略可以归纳成几条：

• 入站和出站是两段独立的认证，MCP token 的 audience 必须是 MCP Server 自己
• 出站用 token exchange 解决：auth server 支持拿入站 token 直接交换的，标准 token exchange 就够了；不支持的（比如 Logto 的 token exchange 需要 subject token 作为输入），用 impersonation 类能力由服务端发起交换
• 多租户不影响机制的选择，organization 上下文是交换时的一个参数，单租户产品不传这个参数就可以了
• AI 代表用户做事，下游 token 的权限必须收敛到用户本人

一个简单的检验方法：假设 MCP client 手里的 token 泄漏，攻击者能做的应该只有「调用 MCP Server 上那几个受控的 tools，且仍受用户权限约束」。如果能直接调到全量 API，说明权限边界有问题。

MCP 生态还在快速演进，入站认证已经被规范覆盖得很好，「MCP Server 如何调用下游」目前还是各家自己发挥的地带。希望我们的实践能给你一些参考。

如果你在给自己的产品做 MCP Server，可以看看 Logto 为 AI 场景提供的完整方案：Auth for AI apps, agents, and MCP servers。想看这套 token 链路的实际效果，可以直接连接 Logto MCP Server 体验。

文中涉及的技术文档：

• User impersonation
• Organizations
• OAuth 2.0 Token Exchange (RFC 8693)
• OAuth 2.0 Protected Resource Metadata (RFC 9728)