远程MCP多用户鉴权：令牌受众、下游委托与代理同意应怎样分开

2025年7月的讨论以一个开发者的实际问题开始：如何让多个用户认证到同一个远程MCP服务器。他们提出的方案很直接——在客户端构建OAuth，将Bearer令牌传给远程MCP服务器，然后让服务器本身在每次工具调用中传递该Bearer令牌。提问者计划使用LibreChat作为客户端（它处理每用户的OAuth令牌并自动在HTTP请求中传给服务器），服务器端不存储任何凭证，只是从HTTP调用中自动提取Bearer令牌并传入工具调用。

已提供的2026-07-28版安全文档，将令牌透传描述为：接收客户端令牌时不验证它是否为MCP服务器签发，随后把它传给下游API。问题落在缺失的受众检查：面向一个资源的凭证，被当作另一个资源的授权依据。核查该捷径因而有了明确落点——追踪令牌的预期接收方，以及每次使用前实际执行的验证。

授权文档的令牌处理要求进一步规定了面向MCP服务器签发令牌的边界。因此，应从验证和委托环节评价提议，而不是以服务器是否存储凭证作为判断依据。本分析采用2026-07-28版文本；2025年7月的答复已经将令牌透传称为反模式。

第一条边界是入站访问令牌的预期接收方。在所述HTTP授权机制中，MCP服务器验证令牌确实面向该MCP资源，客户端则通过RFC 8707资源指示标明目标资源。具体如何验证，取决于令牌格式与授权配置。下文的代理同意控制范围更窄，针对指南中第三方静态客户端ID、MCP客户端动态注册和第三方同意Cookie组合场景。

第二条边界是第三方授权前的逐客户端同意机制。安全最佳实践页面要求MCP代理服务器必须维护按用户批准的client_id注册表，并在发起第三方授权流程之前检查该注册表。这防止了混淆代理攻击：当静态client_id与动态客户端注册和同意Cookie结合时，攻击者可以通过构造利用浏览器现有同意状态的恶意链接，在未经用户明确批准的情况下获取授权码。

第三条边界将MCP服务器访问与下游API授权分开。文档禁止接收或传递非为MCP服务器签发的令牌，并将未经验证的透传描述为反模式。检查实现时，应追踪两次判定：MCP服务器为什么接收入站凭证，以及哪项凭证或委托授权下游API调用。后端凭证也需要有明确的目标资源与授权路径。

客户端在授权与令牌请求中携带必需的resource参数，以标识目标MCP服务器；服务器端则验证令牌的预期目标。二者是同一路径不同位置的互补控制。有效的实现检查，应从请求追踪到令牌签发和验证，而不止于确认OAuth登录成功。

在混淆代理缓解措施描述的代理场景中，指南要求按用户记录已批准的client_id，在发起第三方授权流程前检查，并安全保存同意决定。同意界面要求涵盖请求客户端、第三方权限范围、已注册的重定向URI、CSRF保护和防止被嵌入。实现需要在指定环节执行用户与客户端之间的批准关系，再据此评价具体存储架构。

第三，如果用Cookie跟踪同意决策，它们必须使用__Host-前缀（防止父域或路径设置Cookie），设置Secure、HttpOnly和SameSite=Lax属性，进行加密签名或使用服务器端会话，并绑定到特定client_id而非通用的“用户已同意”标记。第四，MCP代理服务器必须验证授权请求中的redirect_uri与已注册的URI精确匹配，使用精确字符串匹配而非模式匹配或通配符，并在redirect_uri未经重新注册而改变时拒绝请求。

指南中的OAuth state要求，涉及代理同意流程里state的生成、保存和校验，以及同意批准与状态跟踪的先后次序。检查时应将state处理与重定向URI验证、逐客户端同意放在一起。入站令牌验证另有职责：确认凭证为MCP服务器签发。分清这些责任，才能检查每一环实际如何工作。

凭证存储与授权决定存储解决不同问题。同意注册表记录获批客户端ID及用户关系，第三方秘密属于另一类信息。采用同意Cookie时，指南规定Cookie保护，并提供签名Cookie或服务器端会话等方式。因此，可以独立核查逐客户端同意记录及其保护，再检查API凭证存在哪里。

授权文档将授权能力列为可选，并针对HTTP传输描述这一机制；STDIO实现则应从环境取得凭证。混淆代理缓解措施适用于所述代理安排。这些范围决定检查项目：先确认传输方式与凭证方案，再对照相关控制评价实现。

提问者计划采用的LibreChat客户端一侧已经收到逐用户OAuth令牌，并提出服务器端转发方案。这确定了客户端的起点；接下来要查的是MCP服务器的受众验证和下游API的授权路径。参与者另行描述了Apify的API密钥方式。对该方式，应先按API密钥设计检查凭证目标与用户绑定，再判断OAuth专用要求是否适用。

提问者随后链接一个OAuth示例，并称其修复了混淆代理问题。这项声称提供了一个可以继续检查的候选。具体应查看资源参数、入站令牌受众验证，以及该代理设计适用的客户端批准控制。本研究的材料是论坛描述，未检查实现代码。

2025年7月的被选中答复承认仍有疑问，同时已将令牌透传称为反模式。讨论后来依据仓库讨论政策关闭。这条时间线说明，该捷径当时已经进入安全讨论；本次比较的具体要求则取自注明日期的规范文本。

这里能够交付的是要求与证据的对应关系。论坛给出三种被描述的方式，当前文档给出相关边界。评价某个具体实现时，应补齐矩阵列出的请求、验证和同意证据。买方或开发者便可以用相同问题比较实际代码与配置，而不只根据OAuth标签作选择。

对于使用这一授权机制的远程HTTP MCP服务，验收应看清两条路径：入站令牌面向MCP服务器并由其验证，下游API授权另有明确依据。若服务采用指南描述的代理安排，再加上逐用户客户端批准及相关重定向、Cookie和state控制。这是文档支持更充分的设计依据，因为它把简单Bearer转发所掩盖的不同授权判定分别落实。

选择或上线实现前，应索取resource参数、受众验证判定、用户与下游授权的绑定，以及适用时的代理同意记录。这些是本研究提出的评估步骤，尚未实际执行测试。材料不能认证某个参考实现、确定产品当前存在漏洞，或量化运营成本差异。