MCP与OAuth2：谁授权了代理在您的MCP服务器上的操作？

为何工具访问会让身份验证更加复杂

模型上下文协议（MCP）现已成为代理型人工智能的标准基础设施。它为模型提供了一种发现并调用外部工具、资源和服务的方法。无需为大型语言模型与它所使用的每个API单独搭建定制化集成；应用程序只需连接到MCP服务器，即可了解该服务器提供的功能。搜索数据库、在GitHub上提交问题、查询Salesforce数据、发送邮件或从企业系统中获取记录，所有这些操作都归结为同一种操作——即工具调用。

一旦人工智能能够采取行动而不仅仅是回答问题，身份认证与授权问题就会迅速变得复杂。这个人工智能是谁？操控它的人类又是谁？谁授权了该行动，人工智能究竟能做什么？授权所针对的是哪种资源？人工智能能否将这一权限转交给其他服务？最大的问题是：主要用于软件访问受保护资源的OAuth2协议，能否充分体现代表人类行事的自主智能体？

答案很复杂。“代表”这一表述指向了OAuth2的Token Exchange协议。目前的MCP规范并未提及该协议，尽管很容易看出它可能的应用场景，而且它也无法解决下文提到的其他缺陷。

MCP在实践中的运作方式

MCP定义了人工智能客户端与MCP服务器之间的标准协议。其简化结构如下所示。

该人工智能应用即为MCP客户端，而MCP服务器则向其提供各种功能。模型可以发现这些功能，并决定何时调用它们。值得注意的变化在于，大型语言模型不再仅仅负责生成文本，它还参与到特定的协议交互中。

想象一下，有一个助手连接到用于企业问题追踪的MCP服务器上。首先，客户端会询问服务器拥有哪些工具。

{
  "method": "tools/list",
  "params": {}
}

服务器会回复其工具列表。

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

现在模型已知有两种可用功能。假设用户要求它查找开放的认证漏洞，并生成一份总结最严重漏洞的问题报告。该智能体可能会首先发起搜索操作。

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

服务器返回了匹配问题。

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

模型会读取这些结果，选出最重要的那个，然后发出第二次请求。

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

服务器确认已创建。

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

在这里，安全问题变得显而易见。代理已从读取信息转变为执行在系统外部可见的操作。

MCP无法解决身份认证问题

一个常见的误解是认为MCP能够解决身份认证问题，其实并非如此。MCP仅定义了客户端与服务器之间的交互方式，而身份认证与授权则是另外需要处理的问题。

对于基于HTTP的传输方式，当前规范（2026-07-28版本）中的授权部分是以OAuth 2.1为基础构建的。该部分被命名为“授权”，可能是因为这正是OAuth 2.1的核心关注点，尽管它也涵盖了身份认证机制。MCP服务器充当OAuth 2.1保护下的资源，而MCP客户端则充当OAuth 2.1客户端。该规范还引入了受保护资源元数据、授权服务器元数据、资源标识符以及客户端注册与发现功能，并整合了以下这些规范：

• OAuth 2.1 IETF 草案（draft-ietf-oauth-v2-1-13）
• OAuth 2.0 承载令牌使用规范（RFC 6750）
• OAuth 2.0 授权服务器元数据规范（RFC 8414）
• OAuth 2.0 动态客户端注册规范（RFC 7591）
• OAuth 2.0 的资源标识规范（RFC 8707）
• OAuth 2.0 受保护资源元数据规范（RFC 9728）
• 授权服务器发行者识别规范（RFC 9207）
• OAuth 客户端 ID 元数据文档（IETF 草案）
• OpenID Connect Discovery 1.0 及 OpenID Connect 动态客户端注册 1.0 规范

相关规范正在不断收紧。在2026年7月的修订版中，客户端必须检查iss参数以防止授权服务器混淆攻击，客户端凭证将与创建它们的发行方绑定，同时动态客户端注册正在被客户端ID元数据文档取代。OAuth2是否足以满足代理的需求仍是一个未解之谜。

OAuth早于代理概念

OAuth 2.0于2012年标准化，旨在解决一个相当简单的问题：客户端如何在无需知晓资源所有者密码的情况下获得对受保护资源的有限访问权限？

该模型运行效果极为出色，成为了互联网上委托式API访问的基础。不过，自主型AI带来了截然不同的客户端形态。以往OAuth2客户端指的是应用程序，而智能代理则具备自主性、可长时间运行且能执行多步骤操作，它能够动态选择工具、调用多个API、分配任务、代表人类行事，甚至做出人类未曾明确规定的决策。这属于完全不同的授权问题。

并非OAuth本身不安全

不应过度夸大这些批评。RFC 6749确实考虑了安全因素，而OAuth2此后也发展出了完善的安全架构。关键在于，OAuth2本就是一种框架，而非适用于所有现代部署的完整规范协议。实现者可以在安全方面做出诸多选择，随着时间推移，业界逐渐意识到某些选择组合存在危险性。正因如此才有了后续的补充：客户端身份认证与发现机制、受保护的资源元数据及资源标识、相互TLS、DPoP及其他限制发送方的令牌、令牌绑定机制、PKCE以及刷新机制。这些补充日益丰富，最终IETF发布了RFC 9700，这是一份关于OAuth 2.0安全的最佳实践文档，它以RFC 6749、6750和6819为基础，同时废弃了较为薄弱的操作模式。

因此OAuth2并未失败，它只是发生了演变。但这种演变本身恰恰反映了根本问题：随着安全环境日益复杂，最初的抽象模型不断需要额外的机制来弥补不足。

令牌代表什么？

回到之前的例子。用户请求创建某个内容，AI决定调用MCP工具，服务器则收到一个OAuth2访问令牌。那么这个令牌代表什么呢？它可能代表人类用户、AI应用、MCP客户端、代表人类操作的MCP服务器，或是应用与用户之间的某种组合。这些角色并不等同，在略有不同但完全合法的OAuth2流程中，任何一种情况都可能发生。

当MCP服务器调用其他API时，这一点尤为重要。

目前有多个授权域存在重叠。在采取行动之前，服务器可能需要确认用户的身份、执行任务的代理、发起请求的MCP客户端、用户已批准的内容、代理可使用的工具、可访问的下游API，以及该操作是否仍在最初的授权范围内。这远比下面所示的简单结构复杂得多。

困惑的代理人

MCP最严重的安全风险之一就是混淆的代理问题。假设MCP服务器收到了本应发给自身的令牌，随后又调用了下游API。粗心设计的实现可能会直接转发该令牌，而这正是当前MCP安全指南旨在防止的行为。根据规范，服务器必须确认该令牌确实是发给自己的，绝不能将客户端的令牌传递给其他服务。当需要调用上游API时，应获取为该下游资源专门发放的另一直令牌。原则就是如此：

而非这样：

第一种模型会创建独立的信任边界。加入MCP网关会让情况更加复杂，但规则依然不变：绝不能将令牌传递给下游。

OAuth2在MCP中的定位

简化来看，其流程大致如下。

MCP服务器是受保护的资源。客户端先获取访问令牌，然后在每次执行MCP操作时将其提交给服务器，由服务器对其进行验证。这便是传统的OAuth2机制。该规范通过资源标识符（即resource参数）进一步强化了这一机制，使得授权请求能够明确指出该令牌所对应的特定MCP服务器。这固然很好，但并不能神奇地解决所有代理授权问题。

OIDC的新增功能

OAuth2仅能说明客户端被授权访问哪些资源，而OIDC则增加了身份层，用于标识经过认证的主体是谁，这对代理来说非常有用。身份提供方可以对用户进行如下认证：

Alice

OIDC可以提供关于该用户的身份信息，OAuth2可以提供委托授权，随后MCP客户端就能获得一个访问令牌，该令牌代表了针对特定资源授予该客户端的授权。从概念上来看是这样的。

不过仍存在一个概念上的差距：对用户进行身份验证并不意味着授权代理程序的每一个决策。用户可能会允许某个应用程序读取自己的邮件，但这与允许人工智能代理自行决定发送任何邮件是两回事。这是一个策略问题。

作用域的弊端

作用域常常被视为解决方案。例如“日历读取”授权的格式就是如此。

scope=calendar.read

还有这样的发送授权。

scope=email.send

但代理系统暴露出了范围划分的粗糙程度。以普通的发送邮件权限为例。

email.send

它是否允许人工智能给任何人发送邮件？能否发送无限数量的消息？能否发送财务文件或机密的企业数据？能否冒充用户身份？能否在未经确认的情况下发送消息？文档中并未说明这些内容。要做出实际决定，可能需要更多相关背景信息。

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

这看起来更像是基于策略的授权，而非传统的OAuth2权限范围。用旧术语来说，就是粗粒度授权决策与细粒度授权决策之间的区别。

代理作为新的安全主体

这可能是最重要的概念变化。传统应用程序通常具有相对稳定的身份标识，而AI代理则可能是由多个部分动态组合而成的。

那么谁才是安全主体呢？可能是所有这些部分。授权系统需要的表述不能仅仅是“Alice可以访问Salesforce”，而应说明Alice已授权这个通过特定应用程序运行的特定代理，在遵循某些策略的前提下，对Salesforce的相应租户执行特定类型的操作。这样的表述要丰富得多。

这其实与任何系统从大量用户（包括人类和应用程序）中缓存多个访问令牌以获取众多下游资源的方式类似。问题在于，是否可以信任该代理能够保护这些令牌，并在需要为特定用户采取行动时选出正确的令牌。

OAuth2 对代理来说是否已失效？

这种结论并不成立。更准确的表述是，OAuth2 只解决了代理授权问题的一部分，而整个问题比 OAuth2 的覆盖范围更广。它在委托访问方面表现非常好，其实现方式如下。

代理生态系统需要更多答案：由哪个代理代表哪个人，使用何种工具，出于何种目的，访问哪个资源，依据何种授权和策略，持续时间多长，交易限额是多少，以及需要何种人工审批。拥有访问令牌并不能消除这些疑问。

新的提案

目前出现了几种不同的发展方向。

GNAP

最显而易见的基于标准的候选方案是GNAP，即授权协商与授权协议。它旨在突破OAuth2风格的授权与委托机制的局限，能够将授权委托给软件，并将相关结果传递给该软件，涵盖API访问权限以及主体信息。其设计实现了比OAuth2更复杂的委托功能。GNAP现已作为RFC 9635成为IETF的拟议标准，而RFC 9767则涉及资源服务器之间的连接。虽然它回答了是否有人提出了超越OAuth2的方案这一问题，但它并非专门用于替代MCP的方案，且OAuth2依然占据主导地位。

专门针对MCP的安全协议

研究人员还在提出基于MCP和智能体AI的协议。安全模型上下文协议（SMCP）将为MCP增添统一身份管理、相互认证、安全上下文传播、细粒度策略执行以及审计日志功能。另一项提案MCPSec则建议通过能力认证和消息认证来应对MCP特有的威胁。这些努力表明，认证并非唯一需要解决的问题。一个智能体生态系统不仅需要确定用户的身份，还需确认其宣称具备何种能力，以及这些能力是否可以通过加密方式得到验证。这正是向基于能力的安全模型迈进的体现。

基于能力的授权

这或许比取代OAuth更为重要。系统无需向智能体授予email.send这样的权限范围，而是可以赋予其定义更为狭窄的能力。

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

该代理拥有可通过加密方式验证的授权凭证，且不能将此权限用于其他用途。这更接近代理系统所需的功能，因为代理不仅经过了身份验证，还被赋予了特定的权限。

OAuth2与其他技术的结合

最终的架构很可能不会宣布OAuth2已过时，其形态会更接近如下所示。

OAuth2持续颁发访问令牌，OIDC用于确认用户身份，MCP提供工具协议，能力或策略系统限制代理实际可执行的操作，而策略执行点则负责做出最终决策。

缺失的环节：意图

意图是传统授权机制所无法处理的。假设用户要求智能代理查找价格低于1000美元的马尼拉航班并完成预订。在此过程中，代理可能需要查询各航空公司、比较票价、查看日历、调出护照信息、预订座位并支付费用。用户从未逐一批准过这些API请求，而是批准了一个整体意图，这与传统的网页授权方式有显著不同，因为智能代理会将一个宽泛的指令转化为一系列机器可执行的操作。安全系统可能需要对这些操作进行合理分析。

正因如此，只要正确理解这种批评，所谓“OAuth2不适用于智能代理”的说法也有一定道理。OAuth2确实可以授权每一次调用，但它本身并不具备判断这些调用是否符合用户意图以及代理所获授权范围的完整机制。

MCP作为测试案例

MCP迫使身份认证与安全领域面对一个已存在多年的问题。OAuth2正是围绕这一流程设计的。

代理型AI带来了不同的情况。

这一流程变得动态化：参与者可能发生变化，代理会做出决策，工具可以即时被发现，而下游服务甚至可能从未听说过原始用户。然而系统仍需回答是谁授权了该操作，这是个更为棘手的问题。

OAuth2不会消失

有人会认为OAuth2出现于AI之前，因此无法用于AI领域，但这种看法过于简单。OAuth2之所以能在互联网的巨大变革中依然存在，是因为它确实是一个实用的授权框架，而且MCP规范正是基于OAuth 2.1构建的，并未放弃它。更有可能的发展趋势是逐步演进：

• 以OAuth2作为基础
• 用OIDC处理身份认证
• 用于标准工具交互的MCP
• 用于增强令牌绑定的DPoP及相关机制
• 将令牌与其目标资源关联起来的资源指示器
• 用于限制智能体行为的能力系统
• 用于评估上下文的策略引擎
• 用于实现更丰富委托语义的GNAP等新协议

一种理念的转变

智能体AI主要带来的并非新的认证问题，而是授权与委托问题。认证关注的是“你是谁”，而OAuth2关注的是“你可以访问什么”。智能体授权则需要明确：究竟将何种权限委托给了该智能体、代表谁、针对哪些资源、在何种约束条件下，以及该特定操作是否属于授权范围。这是一个更为复杂的问题，因此可能需要更完善的安全模型。

未来很可能不会是OAuth2与某种新技术的对立，而更可能是OAuth2、OIDC、MCP、能力模型、策略机制、更强的加密绑定以及具备代理意识的任务委托共同发挥作用。MCP使得现有身份认证架构的局限性变得不容忽视，这或许会成为它对人工智能生态系统最重要的贡献之一。