--- title: "企业级 MCP 授权架构" canonical: https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/ language: zh description: "一份厂商中立的多租户 MCP 授权参考设计。OAuth 2.1 与 OIDC 流程、resource indicators 与受众校验、禁止令牌透传、按工具的 scope、委托访问、凭据生命周期、租户隔离与审计。" image: "https://wavect.io/img/blog/headers/header_enterprise-mcp-authorization-architecture.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 分钟 阅读 · 2026年7月23日 [**下一篇**](/zh/blog/ai-agent-eval-sandbox-security-checklist/) # 企业级 MCP 授权架构：一份多租户参考设计 要点速览 MCP 授权规范（2025-11-25 修订）给出三条硬性规则：使用 OAuth 2.1，用 resource indicators（RFC 8707）把每个访问令牌绑定到特定受众，且绝不把客户端令牌透传给下游 API。MCP 服务器是校验令牌的 OAuth 资源服务器，而不是签发令牌的授权服务器；签发由你 的身份提供方完成。企业在此之外需要的一切，多租户隔离、按工具的 scope、经 RFC 8693 令牌交换的委托下游访问、凭据生命周期与审计，都在规范之上，是你自己拥有的设计。这是一 份厂商中立的多租户参考架构，画出了完整的信任边界：从身份提供方到资源服务器，再到按租户 隔离的数据面，租户身份来自经过验证的令牌 claim，绝不来自工具输入。 [Model Context Protocol](/zh/glossary/mcp/) 规范终于对授权说了点实在话：使用 OAuth 2.1，用 resource indicators 把每个令牌绑定到特定受众，绝不把客户端令牌透传给下游 API。这些要求是真的。问题在于，它们散落在核心规范、一份安全最佳实践文档和半打 IETF RFC 之间，而几乎每一个为这些关键词排名的页面，都是止步于单服务器场景的安全厂商清单。 这是我们的参考设计，适用于当客户需要一台 MCP 服务器：服务多个租户、对接企业身份提供方、并能通过采购方的安全审查。它厂商中立，锚定在规范 2025-11-25 修订版，并画出了别人都没画的那张图：从身份提供方到按租户隔离数据面的完整信任边界。内容源自 Wavect 在 [AI 产品](/zh/services/artificial-intelligence/) 与 [安全加固](/zh/services/software-quality-assurance/) 上的工作。 这篇文章负责实现 MCP 授权层。如果你还在判断 MCP 本身能否成为边界，请先阅读 [为什么 MCP 不是安全边界，以及数据级访问控制如何补上缺口](/zh/blog/mcp-security-boundary-data-level-access-control/) 。 ## 各司其职：MCP 服务器是资源服务器，不是授权服务器 最常见的错误，是把 MCP 服务器建成它自己的登录系统。它不是。按当前规范，MCP 服务器是一台 OAuth 2.1 **资源服务器**。它的职责是校验令牌，而不是签发令牌。签发由一台独立的**授权服务器**负责，在企业里就是你的身份提供方（Entra ID、Okta、Auth0、Keycloak、Ping），由它与用户交互并签发访问令牌。 这个拆分是近期才有的。第一版授权规范（2025-03-26）期望 MCP 服务器同时充当授权服务器和资源服务器。2025-06-18 修订版通过 [pull request 284](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284) 拆分了这两个角色，正是这个拆分才让企业单点登录成为可能。授权服务器仍然可以与资源服务器同处一地，但 MCP 服务器被规定的职责就是校验令牌。把这个角色模型定对，下游的一切都会各就各位。定错了，你就在拙劣地重造身份系统。 ## 当前规范究竟要求什么？ 表格之前先说两点。第一，MCP 里的授权是**可选的**，且只为 HTTP 传输定义。位于 STDIO 传输之后的服务器根本不该遵循这份规范；它从环境中取凭据。第二，OAuth 2.1 仍是 IETF 草案，不是已发布的 RFC，所以别给它引用 RFC 编号。下面是 2025-11-25 修订版的标准面。 | 标准 | 引用 | 在 MCP 中的角色 | 级别 | | --- | --- | --- | --- | | OAuth 2.1 | draft-ietf-oauth-v2-1 | 核心授权框架 | 授权服务器 MUST | | Protected Resource Metadata | RFC 9728 | 服务器把客户端指向其授权服务器 | 资源服务器 MUST | | Resource Indicators | RFC 8707 | 把令牌绑定到一个受众 | 客户端 MUST | | Authorization Server Metadata | RFC 8414 | 授权服务器发现 | MUST（此项或 OIDC） | | OpenID Connect Discovery | OIDC Core 1.0 | 授权服务器发现的替代方式 | MUST（此项或 8414） | | PKCE | OAuth 2.1 第 7.5.2 节 | 保护 authorization code | 客户端 MUST，用 S256 | | Client ID Metadata Documents | draft-ietf-oauth-client-id-metadata-document | 用 URL 作为 client_id | SHOULD（2025-11-25 新增） | | Dynamic Client Registration | RFC 7591 | 客户端自动注册 | MAY（原为 SHOULD） | | Bearer 令牌用法 | RFC 6750 | challenge 与 insufficient_scope | 被引用 | 注意两处让人栽跟头的版本差异。2025-11-25 修订版把 Dynamic Client Registration 从 SHOULD 降为 MAY，并新增了强制的 PKCE S256 方法，外加要求客户端在开始前先验证 PKCE 支持。如果授权服务器 metadata 没有声明 `code_challenge_methods_supported`，合规的客户端必须拒绝开始该流程。 ## 授权流程从头到尾怎么走？ 整个握手就是一个发现步骤，后接一个标准的 authorization code flow。客户端不带令牌访问服务器，被告知去哪里认证，完成认证，然后带着一个为这台特定服务器签发的令牌回来。 ![MCP OAuth 2.1 授权时序：401 challenge、protected-resource metadata 发现、带 PKCE 和 resource indicator 的 authorization code flow，然后是资源服务器校验的绑定受众 bearer 令牌](/img/blog/posts/mcp-auth-oauth-flow.svg) 那张图里藏着两个必做细节。在 challenge 时，服务器必须按 RFC 9728 返回 `401 Unauthorized`，并带一个携带 `resource_metadata` URL 的 `WWW-Authenticate` 头。2025-11-25 修订版也允许客户端直接探测 well-known URI。在 authorization 和 token 请求里，客户端必须发送一个设为 MCP 服务器规范 URI 的 `resource` 参数，而且无论授权服务器是否声称支持它，都要发送。 ## 为什么禁止令牌透传，以及你如何校验受众？ 这是规范的安全核心，也是大多数自建服务器翻车的地方。规则很直白：MCP 服务器必须校验每个访问令牌都是把它当作目标受众而签发的，并拒绝其他一切。它不得接受为另一个服务签发的令牌，也不得把收到的令牌转发给下游 API。最后这个反模式就是**令牌透传**，规范对它明令禁止。 原因是 confused deputy 问题。如果你的服务器接受并转发它没有校验的令牌，那么为某个服务泄露或签发的令牌，就变成了另一个服务的万能钥匙，基于受众的限流被绕过，下游审计轨迹显示的是错误的身份。校验受众只是一次 claim 检查，而它就是资源服务器与法律责任之间的那条线。 ``` on every tool call: token = bearer_from_authorization_header() # never from a session claims = verify_signature(token, jwks_of(trusted_issuer)) assert claims.iss == expected_issuer # pinned per tenant assert this_server_uri in claims.aud # RFC 8707 audience assert not expired(claims) and not before(claims) assert required_scope_for(tool) in claims.scope tenant = claims["tenant"] or claims["org_id"] enforce_tenant(tenant) # every query, every secret ``` 注意这里没有什么：没有用会话来做认证的查找。规范明确要求服务器校验每一个进入的请求，且不得用会话来做认证。会话标识符，如果你要用的话，必须是非确定性的，并绑定到用户身份，这样猜出来的标识符就无法冒充另一个租户。 ## 服务器如何在不泄露令牌的情况下访问下游 API？ 如果 MCP 服务器需要调用下游 [API](/zh/glossary/api/) ，它就作为该 API 的 OAuth 客户端，使用一个由上游授权服务器签发的独立令牌。规范告诉你不该做什么（不要透传进入的令牌），但把怎么做留给了生态。主流做法是 RFC 8693 定义的**令牌交换**：服务器把受众为 MCP 服务器的进入令牌，换成一个受众为下游 API 的新令牌。 服务器在这里扮演双重角色：对客户端是资源服务器，对 API 是 OAuth 客户端。优先选择委托而非冒充，这样原始用户留在 `sub` claim 里，行动链记录在 `act` claim 里，正是这一点让你的审计轨迹在跨越这一跳后仍然诚实。令牌交换与 on-behalf-of 流程都在 MCP 核心规范之外，所以把它们当作身份提供方或网关的职责，而不是 MCP 的要求。 ## 多租户参考架构长什么样？ 这就是拓扑。一个身份提供方签发绑定受众的令牌，每个租户一个 realm。客户端把这些令牌出示给企业信任边界内一台共享的资源服务器或网关。服务器校验受众、执行按工具的 scope、锁定租户 realm，然后才触达工具、数据和下游 API，每一项都按租户隔离。 ![多租户 MCP 授权架构：各租户客户端从共享身份提供方获得绑定受众的令牌，出示给一台 MCP 网关，网关校验受众、执行按工具的 scope 并锁定租户 realm，再经 RFC 8693 令牌交换触达下游 API，同时数据面、凭据保险库与审计日志按租户隔离](/img/blog/posts/mcp-auth-reference-architecture.svg) 大多数多租户文章的错误，是把隔离当成数据库问题。它不是。多租户必须在每一层执行，而租户身份来自经过验证的令牌 claim，绝不来自模型能影响的工具输入。下面这张表就是我们逐层走的清单。 | 层 | 隔离控制 | 省略后的后果 | | --- | --- | --- | | 身份 | 按租户锁定 issuer 与 realm；拒绝其他 realm 的令牌 | 租户 A 通过租户 B 的 realm 登录 | | 令牌 | 每个请求都校验受众（RFC 8707）与过期 | 在别处签发的令牌被接受 | | Scope | 从 IdP 组和角色映射出的最小权限 scope | 只读角色执行了写操作 | | 工具 | 按租户层级与 scope 过滤可见工具 | 智能体发现一个它无法安全使用的工具 | | 凭据 | 按租户的密钥放在保险库里，对模型和客户端不透明 | 一个租户的 API key 服务了另一个租户 | | 数据 | 基于租户 claim 的行级安全 | 跨租户读取行数据 | | 审计 | 按租户、不可变、带 correlation ID 的日志 | 事故期间无法归因 | ![Kevin Riedl](/img/team/kevin.webp) "租户身份是一个经过验证的令牌 claim。一旦它来自模型可以写入的工具参数，你的隔离就只是演戏。" ## 按工具的 scope 与 step-up 授权如何运作？ 核心协议在 OAuth 层处理 scope，而不是按单个工具，所以真正的按工具授权要你自己在上面搭。规范给了你原语。从最小开始，避免像 `all` 或 `full-access` 这样的大杂烩 scope。当某个工具需要的超出当前令牌所授予的，2025-11-25 修订版定义了一个干净的 step-up：服务器返回 `403`，带 `WWW-Authenticate: Bearer error="insufficient_scope"` 和所需 scope，客户端只为该 scope 做一次增量授权，然后重试。 实践中我们把身份提供方的组和 SCIM 角色映射到 scope，再让每个工具以一个所需 scope 为门槛。分析师角色带 `invoices:read`，能看到只读工具；它永远不带 `ledger:write`。这与我们在 [授权审查](/zh/services/software-quality-assurance/) 里用的是同一套纪律，也正是采购团队真正会去测的东西。 ## 如何为 MCP 服务器加上企业 SSO？ 有两种形态，选择决定了你大部分的运营成本。 第一种是**每台服务器各自 OAuth**：每台 MCP 服务器把它的 `authorization_servers` metadata 指向企业身份提供方。对一两台服务器很干净，到了机队规模就很重复。第二种是 **MCP 网关**：在所有服务器前放一个执行策略的统一入口，集中做发现、令牌校验、scope 映射、令牌交换和审计。对于跨多个租户运行许多服务器的企业，网关通常是正确答案，因为你有一个地方执行隔离，也有一个地方做审计。 关于协议：OIDC 在 2025-11-25 修订版里是一等公民，它要求授权服务器支持 RFC 8414 metadata 或 OpenID Connect Discovery，并要求客户端两者都尝试。MCP 没有原生 SAML。纯 SAML 的企业要通过其身份提供方，或通过一个为 MCP 服务器暴露 OAuth 或 OIDC 前端的 broker 来搭桥。 ## 如何治理客户端注册与凭据生命周期？ Dynamic Client Registration 是早期部署的软肋，因为它让任意客户端都能注册进来。2025-11-25 修订版把它降为 MAY，转而偏好一个三层模型：已知客户端用预注册凭据，然后是 Client ID Metadata Documents（客户端用一个 HTTPS URL 作为 `client_id`），再然后 DCR 作为兜底。如果你允许后两者中的任何一种，请把 issuer 加入 allowlist，并留意规范点名的 SSRF 与 localhost 重定向风险。企业应当把注册绑定到某个租户，并让未知客户端走一条管理员审核队列。 凭据生命周期遵循 OAuth 2.1：签发短寿命访问令牌，为公共客户端轮换 refresh 令牌，安全存储令牌，别把令牌放进 URL query string，并在每个请求都发送 bearer 令牌。我们作为起点使用的具体默认值： | 凭据 | 典型寿命 | 轮换 | | --- | --- | --- | | 访问令牌（客户端到服务器） | 5 到 15 分钟 | 用 refresh 令牌重新签发 | | Refresh 令牌（公共客户端） | 数小时到数天，滑动 | 每次使用都轮换 | | 下游令牌（RFC 8693） | 数分钟，按调用或按会话 | 重新交换，不要大范围缓存 | | 保险库中的按租户密钥 | 长，但可吊销 | 定期加上疑似泄露时 | ## 你必须捕获哪些审计事件？ 核心规范没有专门的审计日志要求，但令牌透传的分析已经替你把理由说清了：透传会破坏审计轨迹，因为下游日志显示的是错误身份。在多租户系统里，审计就是你证明隔离生效的方式。把下面这些按租户记录，并带一个能挺过下游那一跳的 correlation ID。 - **令牌校验结果：** 接受、因受众拒绝、因 issuer 拒绝、已过期。 - **授权决策：** 调用了哪个工具、所需 scope、授予的 scope、放行或拒绝。 - **Step-up 事件：** 请求的 scope 与实际授予的子集。 - **令牌交换：** 为哪个 subject 和 actor 签发了哪个下游受众。 - **租户上下文：** 每条记录都带经过验证的租户 claim，好让一次查询能归因到一个租户、一个用户和一个工具。 ## 按服务器、网关，还是托管身份：你怎么选？ 给三种可行拓扑一张速用决策矩阵。 | 方式 | 最适合 | 成本 | | --- | --- | --- | | 每台服务器各自 OAuth | 一两台服务器、单租户 | 搭建成本低，规模上表现差 | | MCP 网关 | 许多服务器或许多租户 | 搭建成本较高，只有一个执行点 | | 托管 IdP 集成 | 你本来就在 Entra 或 Okta 里 | 厂商锁定，合规最快 | 只要你排好顺序，从单租户服务器走到多租户并不是重写：先引入租户 claim 并锁定 issuer，把密钥搬进按租户的保险库，加上基于该 claim 的行级安全，再过滤工具可见性并打开按租户审计。每一步都能独立交付、独立测试。用对抗方式测试隔离：拿租户 A 的令牌去打租户 B 的数据，确认它在令牌层就被拒绝，而不仅仅是在查询层被过滤。 ## 最终思考 MCP 授权规范给你三条硬性要求：以 OAuth 2.1 为框架、用 resource indicators 绑定受众的令牌、以及禁止令牌透传。其余对企业重要的一切，多租户隔离、按工具的 scope、委托的下游访问与审计，都在规范之上，由你来设计。把 MCP 服务器当成一台负责校验与执行的资源服务器，把租户身份放在一个经过验证的 claim 里，并记录足够多的信息来证明隔离生效。做到这些，MCP 服务器就不再是你智能体栈里最薄弱的一环。 ## 来源与延伸阅读 - [Model Context Protocol, Authorization specification (2025-11-25 revision)](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) - [Model Context Protocol, Authorization specification (2025-06-18 revision)](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) - [Model Context Protocol, Security Best Practices (token passthrough, confused deputy)](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) - [MCP pull request 284, separating the resource server and authorization server roles](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284) - [RFC 9728, OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728) - [RFC 8707, Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) - [RFC 8414, OAuth 2.0 Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414) - [RFC 7591, OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591) - [RFC 8693, OAuth 2.0 Token Exchange](https://www.ietf.org/rfc/rfc8693.pdf) - [RFC 9068, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://www.rfc-editor.org/rfc/rfc9068.html) - [RFC 6750, OAuth 2.0 Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) - [OAuth 2.1 Authorization Framework (IETF draft)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13) ## 你可能也喜欢.. [**AI Agent Evaluation Sandbox Security Checklist** 同一问题的隔离一面：把 egress、凭据和监控留在智能体的控制之外。](/zh/blog/ai-agent-eval-sandbox-security-checklist/) [**Wavect 对比一家通用型开发机构** 通用型机构卖产能。我们卖的是那份安全与产品判断，好交付一个你守得住的智能体栈。](/zh/compare/wavect-vs-dev-agencies/) 智能体工程 ## 继续浏览此集群 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [Linux 是 AI 智能体的最佳操作系统吗？2026 基础设施指南](/zh/blog/linux-for-ai-agents/) - [MCP Cloud 对比 Manufact Cloud：MCP 托管指南](/zh/blog/mcp-cloud-vs-manufact-cloud/) - [如何用 Agent Skills 让 AI 写作更自然](/zh/blog/ai-writing-agent-skills/) - [NVIDIA NOOA 评测：面向对象智能体适合生产环境吗？](/zh/blog/nvidia-nooa-object-oriented-agents-review/) - [Strix AI 渗透测试：2026 年 30 天试点与采购指南](/zh/blog/strix-ai-pentesting-pilot-guide-2026/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 分钟 阅读 · 2026年7月23日 [**下一篇**](/zh/blog/ai-agent-eval-sandbox-security-checklist/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/#webpage", "@type": "WebPage", "dateModified": "2026-07-23", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-23", "url": "https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "MCP 授权规范（2025-11-25 修订）给出三条硬性规则：使用 OAuth 2.1，用 resource indicators（RFC 8707）把每个访问令牌绑定到特定受众，且绝不把客户端令牌透传给下游 API。MCP 服务器是校验令牌的 OAuth 资源服务器，而不是签发令牌的授权服务器；签发由你 的身份提供方完成。企业在此之外需要的一切，多租户隔离、按工具的 scope、经 RFC 8693 令牌交换的委托下游访问、凭据生命周期与审计，都在规范之上，是你自己拥有的设计。这是一 份厂商中立的多租户参考架构，画出了完整的信任边界：从身份提供方到资源服务器，再到按租户 隔离的数据面，租户身份来自经过验证的令牌 claim，绝不来自工具输入。", "articleBody": " 博客概览/AI 与智能体/智能体工程 企业级 MCP 授权架构：一份多租户参考设计 要点速览 MCP 授权规范（2025-11-25 修订）给出三条硬性规则：使用 OAuth 2.1，用 resource indicators（RFC 8707）把每个访问令牌绑定到特定受众，且绝不把客户端令牌透传给下游 API。MCP 服务器是校验令牌的 OAuth 资源服务器，而不是签发令牌的授权服务器；签发由你 的身份提供方完成。企业在此之外需要的一切，多租户隔离、按工具的 scope、经 RFC 8693 令牌交换的委托下游访问、凭据生命周期与审计，都在规范之上，是你自己拥有的设计。这是一 份厂商中立的多租户参考架构，画出了完整的信任边界：从身份提供方到资源服务器，再到按租户 隔离的数据面，租户身份来自经过验证的令牌 claim，绝不来自工具输入。 Model Context Protocol 规范终于对授权说了点实在话：使用 OAuth 2.1，用 resource indicators 把每个令牌绑定到特定受众，绝不把客户端令牌透传给下游 API。这些要求是真的。问题在于，它们散落在核心规范、一份安全最佳实践文档和半打 IETF RFC 之间，而几乎每一个为这些关键词排名的页面，都是止步于单服务器场景的安全厂商清单。 这是我们的参考设计，适用于当客户需要一台 MCP 服务器：服务多个租户、对接企业身份提供方、并能通过采购方的安全审查。它厂商中立，锚定在规范 2025-11-25 修订版，并画出了别人都没画的那张图：从身份提供方到按租户隔离数据面的完整信任边界。内容源自 Wavect 在 AI 产品与安全加固上的工作。 这篇文章负责实现 MCP 授权层。如果你还在判断 MCP 本身能否成为边界，请先阅读为什么 MCP 不是安全边界，以及数据级访问控制如何补上缺口。 各司其职：MCP 服务器是资源服务器，不是授权服务器 最常见的错误，是把 MCP 服务器建成它自己的登录系统。它不是。按当前规范，MCP 服务器是一台 OAuth 2.1 资源服务器。它的职责是校验令牌，而不是签发令牌。签发由一台独立的授权服务器负责，在企业里就是你的身份提供方（Entra ID、Okta、Auth0、Keycloak、Ping），由它与用户交互并签发访问令牌。 这个拆分是近期才有的。第一版授权规范（2025-03-26）期望 MCP 服务器同时充当授权服务器和资源服务器。2025-06-18 修订版通过 pull request 284 拆分了这两个角色，正是这个拆分才让企业单点登录成为可能。授权服务器仍然可以与资源服务器同处一地，但 MCP 服务器被规定的职责就是校验令牌。把这个角色模型定对，下游的一切都会各就各位。定错了，你就在拙劣地重造身份系统。 当前规范究竟要求什么？ 表格之前先说两点。第一，MCP 里的授权是可选的，且只为 HTTP 传输定义。位于 STDIO 传输之后的服务器根本不该遵循这份规范；它从环境中取凭据。第二，OAuth 2.1 仍是 IETF 草案，不是已发布的 RFC，所以别给它引用 RFC 编号。下面是 2025-11-25 修订版的标准面。 标准引用在 MCP 中的角色级别 OAuth 2.1draft-ietf-oauth-v2-1核心授权框架授权服务器 MUST Protected Resource MetadataRFC 9728服务器把客户端指向其授权服务器资源服务器 MUST Resource IndicatorsRFC 8707把令牌绑定到一个受众客户端 MUST Authorization Server MetadataRFC 8414授权服务器发现MUST（此项或 OIDC） OpenID Connect DiscoveryOIDC Core 1.0授权服务器发现的替代方式MUST（此项或 8414） PKCEOAuth 2.1 第 7.5.2 节保护 authorization code客户端 MUST，用 S256 Client ID Metadata Documentsdraft-ietf-oauth-client-id-metadata-document用 URL 作为 client_idSHOULD（2025-11-25 新增） Dynamic Client RegistrationRFC 7591客户端自动注册MAY（原为 SHOULD） Bearer 令牌用法RFC 6750challenge 与 insufficient_scope被引用 注意两处让人栽跟头的版本差异。2025-11-25 修订版把 Dynamic Client Registration 从 SHOULD 降为 MAY，并新增了强制的 PKCE S256 方法，外加要求客户端在开始前先验证 PKCE 支持。如果授权服务器 metadata 没有声明 code_challenge_methods_supported，合规的客户端必须拒绝开始该流程。 授权流程从头到尾怎么走？ 整个握手就是一个发现步骤，后接一个标准的 authorization code flow。客户端不带令牌访问服务器，被告知去哪里认证，完成认证，然后带着一个为这台特定服务器签发的令牌回来。 那张图里藏着两个必做细节。在 challenge 时，服务器必须按 RFC 9728 返回 401 Unauthorized，并带一个携带 resource_metadata URL 的 WWW-Authenticate 头。2025-11-25 修订版也允许客户端直接探测 well-known URI。在 authorization 和 token 请求里，客户端必须发送一个设为 MCP 服务器规范 URI 的 resource 参数，而且无论授权服务器是否声称支持它，都要发送。 为什么禁止令牌透传，以及你如何校验受众？ 这是规范的安全核心，也是大多数自建服务器翻车的地方。规则很直白：MCP 服务器必须校验每个访问令牌都是把它当作目标受众而签发的，并拒绝其他一切。它不得接受为另一个服务签发的令牌，也不得把收到的令牌转发给下游 API。最后这个反模式就是令牌透传，规范对它明令禁止。 原因是 confused deputy 问题。如果你的服务器接受并转发它没有校验的令牌，那么为某个服务泄露或签发的令牌，就变成了另一个服务的万能钥匙，基于受众的限流被绕过，下游审计轨迹显示的是错误的身份。校验受众只是一次 claim 检查，而它就是资源服务器与法律责任之间的那条线。 on every tool call: token = bearer_from_authorization_header() # never from a session claims = verify_signature(token, jwks_of(trusted_issuer)) assert claims.iss == expected_issuer # pinned per tenant assert this_server_uri in claims.aud # RFC 8707 audience assert not expired(claims) and not before(claims) assert required_scope_for(tool) in claims.scope tenant = claims[\"tenant\"] or claims[\"org_id\"] enforce_tenant(tenant) # every query, every secret 注意这里没有什么：没有用会话来做认证的查找。规范明确要求服务器校验每一个进入的请求，且不得用会话来做认证。会话标识符，如果你要用的话，必须是非确定性的，并绑定到用户身份，这样猜出来的标识符就无法冒充另一个租户。 服务器如何在不泄露令牌的情况下访问下游 API？ 如果 MCP 服务器需要调用下游 API，它就作为该 API 的 OAuth 客户端，使用一个由上游授权服务器签发的独立令牌。规范告诉你不该做什么（不要透传进入的令牌），但把怎么做留给了生态。主流做法是 RFC 8693 定义的令牌交换：服务器把受众为 MCP 服务器的进入令牌，换成一个受众为下游 API 的新令牌。 服务器在这里扮演双重角色：对客户端是资源服务器，对 API 是 OAuth 客户端。优先选择委托而非冒充，这样原始用户留在 sub claim 里，行动链记录在 act claim 里，正是这一点让你的审计轨迹在跨越这一跳后仍然诚实。令牌交换与 on-behalf-of 流程都在 MCP 核心规范之外，所以把它们当作身份提供方或网关的职责，而不是 MCP 的要求。 多租户参考架构长什么样？ 这就是拓扑。一个身份提供方签发绑定受众的令牌，每个租户一个 realm。客户端把这些令牌出示给企业信任边界内一台共享的资源服务器或网关。服务器校验受众、执行按工具的 scope、锁定租户 realm，然后才触达工具、数据和下游 API，每一项都按租户隔离。 大多数多租户文章的错误，是把隔离当成数据库问题。它不是。多租户必须在每一层执行，而租户身份来自经过验证的令牌 claim，绝不来自模型能影响的工具输入。下面这张表就是我们逐层走的清单。 层隔离控制省略后的后果 身份按租户锁定 issuer 与 realm；拒绝其他 realm 的令牌租户 A 通过租户 B 的 realm 登录 令牌每个请求都校验受众（RFC 8707）与过期在别处签发的令牌被接受 Scope从 IdP 组和角色映射出的最小权限 scope只读角色执行了写操作 工具按租户层级与 scope 过滤可见工具智能体发现一个它无法安全使用的工具 凭据按租户的密钥放在保险库里，对模型和客户端不透明一个租户的 API key 服务了另一个租户 数据基于租户 claim 的行级安全跨租户读取行数据 审计按租户、不可变、带 correlation ID 的日志事故期间无法归因 \"租户身份是一个经过验证的令牌 claim。一旦它来自模型可以写入的工具参数，你的隔离就只是演戏。\" 按工具的 scope 与 step-up 授权如何运作？ 核心协议在 OAuth 层处理 scope，而不是按单个工具，所以真正的按工具授权要你自己在上面搭。规范给了你原语。从最小开始，避免像 all 或 full-access 这样的大杂烩 scope。当某个工具需要的超出当前令牌所授予的，2025-11-25 修订版定义了一个干净的 step-up：服务器返回 403，带 WWW-Authenticate: Bearer error=\"insufficient_scope\" 和所需 scope，客户端只为该 scope 做一次增量授权，然后重试。 实践中我们把身份提供方的组和 SCIM 角色映射到 scope，再让每个工具以一个所需 scope 为门槛。分析师角色带 invoices:read，能看到只读工具；它永远不带 ledger:write。这与我们在授权审查里用的是同一套纪律，也正是采购团队真正会去测的东西。 如何为 MCP 服务器加上企业 SSO？ 有两种形态，选择决定了你大部分的运营成本。 第一种是每台服务器各自 OAuth：每台 MCP 服务器把它的 authorization_servers metadata 指向企业身份提供方。对一两台服务器很干净，到了机队规模就很重复。第二种是 MCP 网关：在所有服务器前放一个执行策略的统一入口，集中做发现、令牌校验、scope 映射、令牌交换和审计。对于跨多个租户运行许多服务器的企业，网关通常是正确答案，因为你有一个地方执行隔离，也有一个地方做审计。 关于协议：OIDC 在 2025-11-25 修订版里是一等公民，它要求授权服务器支持 RFC 8414", "articleSection": "工程", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-23", "datePublished": "2026-07-23", "description": "MCP 授权规范（2025-11-25 修订）给出三条硬性规则：使用 OAuth 2.1，用 resource indicators（RFC 8707）把每个访问令牌绑定到特定受众，且绝不把客户端令牌透传给下游 API。MCP 服务器是校验令牌的 OAuth 资源服务器，而不是签发令牌的授权服务器；签发由你 的身份提供方完成。企业在此之外需要的一切，多租户隔离、按工具的 scope、经 RFC 8693 令牌交换的委托下游访问、凭据生命周期与审计，都在规范之上，是你自己拥有的设计。这是一 份厂商中立的多租户参考架构，画出了完整的信任边界：从身份提供方到资源服务器，再到按租户 隔离的数据面，租户身份来自经过验证的令牌 claim，绝不来自工具输入。", "headline": "企业级 MCP 授权架构：多租户参考设计", "image": "https://wavect.io/img/blog/headers/header_enterprise-mcp-authorization-architecture.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/", "wordCount": 698 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/enterprise-mcp-authorization-architecture/", "name": "企业级 MCP 授权架构 | ", "position": 5 } ] } ```