办公智能体调用 MCP 服务并接入统一认证授权服务：通用架构方案

办公智能体调用 MCP 服务并接入统一认证授权服务：通用架构方案

涂阿燃的网络日志：FDE・KOL・OPC｜记录 AI 实践、社会洞察、生活随笔

办公智能体一旦能读取合同、发起审批、查询客户资料，MCP 地址就不再是一条普通配置。它实际建立了一条“某个应用代表某个用户访问某项企业能力”的授权链路。

这条链路适合交给 OAuth 处理。MCP 负责规定客户端怎样发现受保护资源及其授权服务器，统一认证授权服务负责认证与发证，MCP 服务负责最后一道业务授权。

本文依据 2026-07-16 可访问的 MCP 2025-11-25 授权规范及 IETF 正式 RFC 整理。OAuth 2.1 目前仍是 IETF 草案：MCP 2025-11-25 规范引用 draft-13，IETF Datatracker 当前版本为 2026-03-02 更新的 draft-15。它不应被误写成已经发布的 RFC。

一、一句话架构定义

办公智能体以 OAuth Client 身份，通过 MCP Protected Resource Metadata 发现统一认证授权服务，使用 Authorization Code + PKCE 获取限定到目标 MCP 服务的用户委托凭证，再由 MCP 服务完成 Token 校验、Tool 权限判断和下游凭证隔离。

简单说，统一认证授权服务回答“用户是谁、用户把什么范围授权给哪个客户端”，MCP 服务回答“这次 Tool 调用在当前业务上下文中能不能执行”。两层判断缺一不可。

二、概要架构图

image.png

图 1：统一认证授权服务负责身份与委托，MCP 服务保留 Tool 和业务数据的最终授权权力。

三、参与方及职责边界

边界的关键在于，身份认证集中在统一认证授权服务，业务授权留在资源所在的一侧。用户登录成功只证明“这个人是谁”。它没有自动授予所有 MCP Tool。

四、阶段一：MCP 配置与授权连接的完整时序

1、配置与首次挑战

1. 用户在办公智能体中输入或选择 MCP Endpoint。
2. 办公智能体先做 URL、TLS、DNS 和 SSRF 策略检查，再向 MCP 服务发起不带 Token 的初始化或能力请求。
3. 受保护的 MCP 服务返回 401 Unauthorized。它可以在 WWW-Authenticate: Bearer 中带上 resource_metadata 和建议的 scope。
4. 按当前 MCP 规范，WWW-Authenticate 中的 resource_metadata 并非唯一发现方式。客户端还必须支持 RFC 9728 的 well-known 回退地址。

例如：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
  scope="documents:read"

2、发现受保护资源

1. 办公智能体获取 Protected Resource Metadata（PRM）。文档至少应正确声明 resource，MCP 规范还要求 authorization_servers 至少包含一个授权服务器。
2. 客户端必须验证 PRM 中的 resource 与自己访问的资源标识完全一致。通过 WWW-Authenticate 获得元数据地址时，也要按 RFC 9728 校验它与原始资源请求的绑定关系。
3. 客户端不应直接信任任意元数据 URL。应限制 HTTPS、阻断私网和云元数据地址、限制重定向、响应大小和 DNS 变化，防止 SSRF。
4. 如果 PRM 给出多个授权服务器，办公智能体按企业信任策略选择。高安全场景适合维护 MCP Resource 与统一认证授权服务的允许关系，并与授权服务器元数据中的 protected_resources 交叉检查。

一个最小 PRM 示例：

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://auth.example.com/tenant-a"],
  "scopes_supported": ["documents:read", "documents:write"],
  "bearer_methods_supported": ["header"],
  "resource_name": "企业文档 MCP"
}

3、发现统一认证授权服务与客户端身份

1. 办公智能体根据授权服务器 issuer 获取 RFC 8414 Authorization Server Metadata 或 OIDC Discovery 元数据。带路径的 issuer 必须按 MCP 规定的顺序尝试 well-known 地址，不能自行猜 /authorize 和 /token。
2. 客户端核对返回的 issuer，读取 authorization_endpoint、token_endpoint、code_challenge_methods_supported、scopes_supported、revocation_endpoint、introspection_endpoint、jwks_uri 及客户端注册能力。
3. MCP 客户端必须确认授权服务器支持 PKCE，且应使用 S256。发现元数据没有相应能力时，当前 MCP 规范要求停止流程。
4. 办公智能体取得 Client ID。受控企业环境优先预注册；开放生态可使用 Client ID Metadata Document；兼容旧部署时再使用 RFC 7591 动态客户端注册。

4、授权事务与用户交互

1. 办公智能体生成高熵 state、code_verifier，计算 code_challenge=S256(code_verifier)，并在本地建立一次性授权事务。
2. 客户端把用户代理导向统一认证授权服务的 Authorization Endpoint。请求中包含 response_type=code、client_id、精确注册的 redirect_uri、最小 scope、state、code_challenge、code_challenge_method=S256 和目标 MCP 的 resource。
3. 当前 MCP 授权规范要求客户端在授权请求和 Token 请求中都携带 RFC 8707 resource，其值为目标 MCP 服务的规范资源标识。
4. 用户在统一认证授权服务完成账号密码、企业单点登录、扫码、短信或 MFA。具体认证方法是统一认证授权服务内部能力，对 OAuth Client 仍表现为同一个授权事务。
5. 统一认证授权服务展示同意页，说明办公智能体名称、MCP 服务、请求的数据与操作范围、有效期、风险提示和撤销入口。用户可以同意、缩小范围或拒绝。
6. 认证与同意完成后，统一认证授权服务生成一次性、短时授权码，并把浏览器重定向到已注册的 redirect_uri，返回 code 与原 state。

浏览器、H5 和二维码可以复用同一授权页面。二维码只承载短时、一次性的授权事务入口，不能放 Access Token、Refresh Token 或用户身份信息。扫码后应在手机和原设备显示一致的客户端、MCP 和校验短码，避免登录 CSRF 与错绑。

无法安全接收浏览器回调的无头设备，可以另行采用 OAuth Device Authorization Grant（RFC 8628）。它与 Authorization Code + PKCE 是两种授权方式，不宜把轮询设备码伪装成浏览器回调。

5、换取凭证与建立连接

1. 办公智能体先严格比较 state，再向 Token Endpoint 提交授权码、相同 redirect_uri、原 code_verifier、client_id 和相同目标 resource。
2. 统一认证授权服务验证授权码未过期、未使用，核对 Client、Redirect URI、PKCE、Resource 和授权范围。
3. 验证通过后，统一认证授权服务签发面向该 MCP Resource 的 Access Token。是否签发 Refresh Token 由客户端类型、授权策略和 Scope 决定，不能假定每次都有。
4. 办公智能体把 Refresh Token 写入操作系统凭证库、硬件保护区或服务端加密保险库；Access Token 尽量只放内存或短时加密缓存。
5. 办公智能体带 Access Token 重试 MCP 请求。成功后，把连接状态标记为“已连接”，并记录 issuer、resource、client_id、subject 连接键、scope、到期时间和 Token 家族标识。

五、认证授权时序图

image.png

图 2：授权码经浏览器返回，Token 通过后端 Token Endpoint 交换；授权请求与 Token 请求都绑定同一个 resource。

六、阶段二：MCP 服务调用与鉴权的完整时序

1. 用户在办公智能体中选择或触发一个 MCP Tool。
2. 办公智能体先根据本地连接记录确认 Resource、Scope 和 Token 到期时间。每个 HTTP 请求都携带凭证，不能把 MCP Session ID 当作认证依据。
3. 办公智能体使用 Authorization: Bearer <access-token> 请求 MCP 服务。启用 DPoP 时改用 DPoP 方案并附带每次请求的证明。
4. MCP 服务从 Header 读取 Token，拒绝 Query String 中的 Token，并设置日志脱敏。
5. JWT 路线：MCP 服务按可信 issuer 选择缓存的 JWK，验证签名、算法、typ、iss、aud、exp、nbf、iat、client_id、scope、租户和可选 cnf。resource 请求参数通常落实为 Access Token 的目标 aud，不能机械要求 JWT 一定存在名为 resource 的 Claim。
6. Introspection 路线：MCP 服务用自己的机密客户端身份调用统一认证授权服务，确认 active=true，并检查 iss、aud、client_id、sub、scope、到期时间和租户信息。
7. MCP 服务得到 iss + sub 代表的稳定用户主体、tenant_id、client_id 和 Scope。手机号、邮箱、显示名只作为可变属性，不能作为跨系统主键。
8. MCP 服务查找 Tool Policy，例如 documents.search -> documents:read，再叠加用户角色、部门、数据归属、租户、环境、时间和风险等级等 ABAC 条件。
9. 高风险 Tool 可以要求更高认证强度或最近认证时间。条件不满足时返回可解释的 403，并触发增量授权或二次认证。
10. 判断通过后，MCP 服务为下游业务服务取得独立 Token。可使用面向下游 audience 的 On-Behalf-Of / Token Exchange，也可使用 MCP 服务自己的服务身份并传递经签名、可审计的用户上下文。
11. 下游服务再次执行自身权限判断。MCP Tool 到下游操作应有明确映射，不能让通用 Tool 绕过下游权限。
12. MCP 服务返回最小必要数据，并记录授权决策、Tool、用户、客户端、租户、资源、结果、耗时和关联 ID。日志不得写入原始 Token、授权码或敏感 Tool 参数全文。
13. Access Token 到期时，办公智能体向 Token Endpoint 提交当前 Refresh Token 和 resource。统一认证授权服务签发新 Access Token，并按策略轮换 Refresh Token。
14. 检测到旧 Refresh Token 重放时，统一认证授权服务撤销整个 Token Family，要求用户重新授权。
15. 用户解除连接时，办公智能体调用 Revocation Endpoint，优先撤销 Refresh Token，清除本地凭证和连接状态。退出登录、管理员撤权、账号禁用和租户离职也应触发对应撤销策略。

HTTP 状态码应保持清楚：

机器人手臂

七、统一认证授权服务需要提供的能力

1、协议端点

• RFC 8414 Authorization Server Metadata 和 / 或 OIDC Discovery；MCP 兼容部署应让客户端能够得到 PKCE 能力。
• Authorization Endpoint、Token Endpoint、JWK Set Endpoint。
• Token Revocation Endpoint（RFC 7009）。
• Token Introspection Endpoint（RFC 7662），如果采用不透明 Token 或需要实时状态校验。
• 可选的 Dynamic Client Registration Endpoint（RFC 7591）。
• 可选的 Device Authorization Endpoint，用于无头设备。
• 支持 RFC 8707 resource，并把它映射为受众受限的 Token。

2、身份认证

• 账号密码、企业 SSO、短信、扫码、MFA 等认证方式的统一编排。
• 会话管理、账号锁定、异常登录检测、设备与风险信息。
• acr、amr、auth_time 等认证强度和时间信息，供高风险操作做 Step-up 判断。
• 以 iss + sub 为主体主键；在多租户场景中稳定传递 tenant_id。

3、授权与同意

• 以 user + client + resource + scope + tenant 为核心的 Consent Grant。
• 首次授权、增量授权、降权、拒绝和撤销。
• 同意页展示客户端身份、目标 MCP、数据类型、操作范围、期限和风险。
• Scope 目录、描述、多语言文案、风险级别及与 Resource 的合法组合。
• 高风险 Scope 的二次认证、短时授权或逐次确认。

4、客户端管理

• 预注册客户端生命周期、Redirect URI、应用名称、所有者和信任等级管理。
• Client ID Metadata Document 的获取、验证、缓存与域名信任策略。
• DCR 的初始访问令牌、配额、审核、软件声明、速率限制和清理机制。
• 公共客户端与机密客户端分级；机密客户端支持可靠的客户端认证和密钥轮换。

5、Token 生命周期

• 一次性授权码；受 Client、Redirect URI、PKCE、Resource、Scope 和用户会话绑定。
• 短期 Access Token，支持 JWT 或不透明格式。
• Refresh Token 轮换、Token Family、重放检测、绝对与空闲有效期。
• 撤销、账号禁用、权限变更和风险事件的传播。
• JWT 签名密钥生成、HSM 或等效保护、JWK 发布、kid 管理、轮换和重叠窗口。
• 可选 DPoP 或 mTLS 的发送者约束 Token。

6、治理与运维

• 登录、认证因子、同意、授权码、Token 签发、刷新、撤销、Introspection 和管理操作审计。
• 按租户隔离数据、密钥、管理员权限和策略。
• 限流、反自动化、可疑客户端注册检测、告警和应急吊销。
• 只向 Token 放入资源服务器真正需要的 Claim，支持日志脱敏和数据保留周期。

八、办公智能体需要实现的能力

• MCP Endpoint 配置、TLS 验证、域名提示、连接状态和断开入口。
• 401 与 WWW-Authenticate 解析，以及 RFC 9728 well-known PRM 回退。
• PRM 的 resource 精确校验、多授权服务器选择和 SSRF 防护。
• RFC 8414 与 OIDC Discovery，多路径 issuer 发现与 issuer 精确校验。
• 预注册、Client ID Metadata Document、DCR 三类 Client ID 获取策略。
• Authorization Code + PKCE S256，安全生成和验证 state，精确处理 Redirect URI。
• 浏览器、H5、二维码的授权事务衔接；二维码中不放凭证。
• 在授权请求和 Token 请求中发送相同的 resource。
• Scope 最小化、403 增量授权、用户拒绝和取消处理。
• Access Token 自动附加、到期判断、单飞刷新，避免并发刷新造成 Token 重放误报。
• Refresh Token 使用系统凭证库、硬件保护区或服务端加密保险库；不得写入配置文件、日志或普通数据库明文列。
• 以 issuer + resource + client_id + tenant + subject 隔离凭证，防止跨 MCP 选错 Token。
• 撤销、清除、账号切换、租户切换和 Token Family 失效后的重新授权。
• 可选 DPoP 密钥生成与每请求证明。

Web 端还需要区分两种形态。纯浏览器 SPA 属于公共客户端，不能保存 Client Secret；更稳妥的企业办公应用通常采用 BFF，由服务端作为机密客户端持有 Refresh Token，浏览器只持有受保护的站内会话。桌面端和移动端也属于公共客户端，应依赖 PKCE、精确 Redirect URI、系统安全存储和 Refresh Token 轮换，不能把内置 Secret 当作秘密。

九、MCP 服务需要实现的能力

• RFC 9728 Protected Resource Metadata，以及 WWW-Authenticate 或 well-known 发现入口。
• 为每个公开 MCP Endpoint 定义唯一、稳定、HTTPS 的规范 Resource Identifier。
• Bearer / DPoP Header 解析，拒绝 URL Query Token。
• JWT 验证器或 Introspection Client；可信 issuer、audience、算法和 JWK 配置不得由请求方控制。
• Token Claim 到安全上下文的映射：主体、租户、客户端、Scope、角色、认证强度。
• Tool 权限注册表：每个 Tool 对应的最小 Scope、业务角色、数据域、风险级别和是否需要 Step-up。
• 401、403 和 insufficient_scope Challenge；支持增量授权。
• 租户隔离、对象级和行级权限，不能只检查 Tool 名称。
• 下游独立凭证、Token Exchange / On-Behalf-Of 或服务身份方案，禁止 Token Passthrough。
• 审计、限流、幂等、敏感操作确认、异常检测和关联追踪。
• 在统一认证授权服务短时不可用时的明确降级策略。

统一认证授权服务不可用时，JWT 本地验证可以继续接受签名有效且未过期的 Token，前提是 JWK 已安全缓存。新 kid 无法获取、Token 已过期或刷新失败时应拒绝，不能跳过校验。Introspection 方案默认 Fail Closed；可以使用很短的正向缓存维持只读请求，但高风险写操作不宜依赖过期状态。

十、Token 与身份数据模型建议

1、主体模型

用户稳定主键建议使用：

subject_key = issuer + "|" + sub
tenant_subject_key = issuer + "|" + tenant_id + "|" + sub

sub 只在对应 issuer 的命名空间内有意义。手机号、邮箱、工号、昵称都可能变化，也可能被回收或在不同租户重复，适合作为属性和检索入口，不适合作为授权主键。对外部 MCP 可以使用 pairwise subject，减少跨服务关联用户的能力。

2、授权 Grant

{
  "grant_id": "gr_...",
  "issuer": "https://auth.example.com/tenant-a",
  "subject": "user-opaque-id",
  "tenant_id": "tenant-a",
  "client_id": "https://agent.example.com/oauth/client.json",
  "resource": "https://mcp.example.com/mcp",
  "scopes": ["documents:read", "documents:write"],
  "consented_at": "2026-07-16T01:30:00Z",
  "expires_at": "2026-10-14T01:30:00Z",
  "status": "active",
  "auth_context": { "acr": "mfa", "amr": ["pwd", "otp"] }
}

Grant 表达用户的长期同意。Token 是这个 Grant 在一段时间内、面向特定 Resource 的可用凭证。二者应分开建模，这样才能做到撤销同意、轮换 Refresh Token，又保留完整审计历史。

3、凭证生命周期建议

这些数字是通用工程基线，不是 OAuth 强制值。企业应根据数据敏感度、交互成本、设备可信度和撤销时效设定。

4、JWT Access Token 建议

采用 RFC 9068 Profile 时，建议包含并校验：

resource 是授权请求与 Token 请求参数。对于 JWT，它通常决定 aud。如果自定义 Token Profile 还放入 resource Claim，可以额外验证；不能用自定义 Claim 代替 aud 校验。

5、Scope、Tool 与业务权限

Scope 适合表达稳定、可向用户解释的能力，例如：

documents:read
documents:write
approval:read
approval:submit
contacts:read

不建议为每一个动态 Tool 或每一条数据生成 Scope。更合适的映射是：

允许执行 = Token 有所需 Scope
        AND 用户拥有业务角色
        AND 用户可访问目标对象
        AND 租户一致
        AND 当前认证强度满足风险策略

例如，approval.submit 需要 approval:submit，还要检查发起人是否属于目标组织、金额是否超过审批额度、数据是否属于当前租户。用户认证成功不会绕过这些条件。

十一、JWT 本地校验与 Token Introspection 对比

推荐采用风险分层：普通读操作使用 5—10 分钟 JWT，本地校验；高风险写操作可以使用不透明 Token + Introspection，或在 JWT 校验后再查询高风险授权状态。无论哪种方案，MCP 服务都要做 Tool 和业务级权限判断。

十二、客户端注册方案对比

当前 MCP 规范给出的优先顺序是：已有预注册信息时先用预注册；否则在授权服务器声明支持时使用 Client ID Metadata Document；再以 DCR 作为回退；最后才让用户手工输入。

群山倒影于平静湖面

公共客户端不能安全保存 Client Secret。把 Secret 编译进桌面程序、移动 App 或前端 JavaScript，只会把它变成可提取的公开字符串。机密 Web/BFF 客户端可以在受控服务端保存 Secret，最好使用非对称客户端认证或等效的可轮换机制。

Redirect URI 必须精确注册和精确比较。桌面端可使用 loopback localhost 回调并配合随机端口；移动端优先使用可验证归属的 HTTPS App Link / Universal Link。所有场景都要结合 PKCE 和 state，防止授权码被其他客户端截获和登录事务错绑。

十三、下游系统访问方案

MCP 服务不能把办公智能体传入的 Token 原样交给下游。当前 MCP 安全规范明确禁止 Token Passthrough，原因包括 audience 混乱、控制绕过、审计失真和混淆代理攻击。

推荐三种模式：

审计链至少保留：最终用户 sub、办公智能体 client_id、MCP 服务身份、下游服务身份、原始授权 Grant、Tool 名、资源对象和全链路 correlation_id。下游 Token 的 audience、scope 和生命周期都应独立于 MCP Token。

十四、主要安全风险及应对措施

签名 Key 建议在受保护的密钥系统中生成和使用，私钥不得进入应用配置。轮换时先发布新公钥，再签发新 kid 的 Token，保留旧公钥直到所有旧 Token 的最大生命周期结束。发生私钥泄漏时需要走紧急吊销流程，不能只等待自然过期。

十五、对原始 11 步方案的合理性评估

1、合理的内容

• 办公智能体主动访问 MCP，由受保护资源给出认证发现信息，方向正确。
• MCP 服务作为 Resource Server，统一认证授权服务作为 Authorization Server，职责划分正确。
• 用户通过浏览器、H5 或二维码完成认证与同意，符合用户代理参与授权的思路。
• 办公智能体持 Access Token 调用 MCP，MCP 服务验证 Token 并结合 Tool 业务权限做最终判断，方向正确。
• Access Token 过期后由办公智能体刷新，用户解除连接或撤销后使凭证失效，生命周期方向正确。

2、明确错误

没有发现已经明确描述、且可以直接判定违反标准的步骤。

这里需要保持克制。概要方案没有写到某个安全参数，通常属于“尚未展开”；语句可能包含多种实现方式，则属于“设计歧义”。不能因为没看到细节，就直接下结论说方案错误。

3、设计歧义

4、尚未展开

• Authorization Code + PKCE、state、Redirect URI 精确匹配。
• 授权请求与 Token 请求中的 resource，以及 Access Token audience 绑定。
• RFC 9728 PRM 的 resource 校验、多授权服务器选择和 SSRF 防护。
• RFC 8414 与 OIDC Discovery 的路径规则和 issuer 校验。
• 预注册、Client ID Metadata Document、DCR 的选择与反滥用。
• Scope 与 Tool、角色、对象级权限、租户和 Step-up 的映射。
• JWT / Introspection 选型、统一认证授权服务故障时的策略。
• Refresh Token 安全存储、轮换、重放检测和 Token Family。
• 撤销对短期 JWT、缓存和下游 Token 的传播方式。
• 下游 Token 隔离、Token Exchange 与完整审计链。
• JWK 轮换、Claim 最小化、日志脱敏、限流和事件告警。

十六、推荐架构

推荐采用“发现层、授权层、资源授权层、下游委托层”四层结构。

1、发现层

每个 MCP Endpoint 发布 RFC 9728 PRM。办公智能体从 401 Challenge 或 well-known 地址发现 PRM，再通过 authorization_servers 找到统一认证授权服务。客户端验证 resource、issuer、TLS 和信任关系，并完成 SSRF 防护。

2、授权层

统一认证授权服务处理认证、MFA、Consent、Client 和 Token。桌面、移动、SPA 都按公共客户端处理，使用 Authorization Code + PKCE；企业 Web 应用优先采用 BFF 机密客户端。授权与 Token 请求都带 resource。

3、资源授权层

MCP 服务只接受 audience 为自己的 Access Token。Token 通过后，还要执行 Scope、Tool Policy、角色、租户、对象级权限和风险策略。高风险 Tool 采用增量授权、最近 MFA 或逐次确认。

4、下游委托层

MCP Token 停在 MCP 服务边界。调用下游时换取面向下游的独立 Token，或使用服务身份加可审计用户上下文。每一跳都有独立 audience、最小 Scope 和审计主体。

十七、落地步骤

第 0 步：先建立资产清单

列出全部 MCP Endpoint、Tool、数据等级、下游系统、租户边界和高风险操作。没有这张表，Scope 会变成随意命名，Consent 也无法说清用户授权了什么。

第 1 步：定义 Resource 与 Scope

为每个 MCP 设定唯一、稳定的 HTTPS Resource Identifier。建立 Tool -> Scope -> 业务角色 -> 数据条件 -> 风险等级 权限矩阵，先覆盖只读与低风险 Tool。

第 2 步：打通标准发现

MCP 服务发布 PRM；统一认证授权服务发布 RFC 8414 / OIDC Discovery；办公智能体实现 401、well-known、issuer 路径、元数据校验和 SSRF 防护。

第 3 步：完成授权码 + PKCE

先选择客户端注册策略，注册精确 Redirect URI。实现 state、PKCE S256、浏览器回调、resource 双请求携带、最小 Scope 和拒绝处理。二维码只做同一事务的入口展示。

第 4 步：建立 Token 基线

低风险场景先用 5—10 分钟 JWT Access Token，Refresh Token 轮换。MCP 严格校验 iss、aud、时间、client_id、Scope 和租户。高风险 Tool 再引入 Introspection、DPoP 或更短 Token。

第 5 步：接入业务授权

把每个 Tool 接入权限矩阵和对象级数据过滤。统一测试 401、403、增量授权、跨租户、账号禁用、角色变化和并发刷新。

第 6 步：隔离下游 Token

逐个下游选择 Token Exchange、服务身份加用户上下文，或独立用户 OAuth。禁止原样透传 MCP Token，并在下游再次验证 audience 与权限。

第 7 步：补齐撤销和审计

实现 Revocation Endpoint、Token Family、重放检测、权限变更事件、JWK 轮换和端到端关联 ID。做一次完整演练：用户撤销、员工离职、客户端被封禁、Key 泄漏后，多久能让所有调用停止。

第 8 步：分风险上线

第一批只开放只读 Tool；第二批开放可逆写操作；敏感、不可逆或涉及资金与外发的 Tool 最后上线，并增加逐次确认、MFA、幂等键和人工审批。

十八、最终判断

原始架构方向正确，可以作为概要蓝图。它目前停在“角色和主流程”层面，离可上线的安全设计还差四个决定性细节：目标 Resource 绑定、公共客户端 PKCE、MCP 与下游 Token 隔离、撤销与业务权限闭环。

最稳妥的实现方式，是让每一方只相信自己能验证的内容。办公智能体不自报用户身份，MCP 服务不接受错误 audience，统一认证授权服务不替业务系统决定对象权限，下游也不接受上一跳的通用 Token。这样，办公智能体获得的是一段可限制、可审计、可撤销的用户委托。

陈年书架的纵深

十九、信息来源

MCP 官方资料

• MCP 2025-11-25 Authorization Specification
• MCP Security Best Practices
• MCP Client Registration 演进说明

IETF 与开放标准

• OAuth 2.1 Authorization Framework 当前草案
• RFC 9728：OAuth 2.0 Protected Resource Metadata
• RFC 8414：OAuth 2.0 Authorization Server Metadata
• RFC 8707：Resource Indicators for OAuth 2.0
• RFC 9700：Best Current Practice for OAuth 2.0 Security
• RFC 7636：Proof Key for Code Exchange
• RFC 9068：JWT Profile for OAuth 2.0 Access Tokens
• RFC 7662：OAuth 2.0 Token Introspection
• RFC 7009：OAuth 2.0 Token Revocation
• RFC 7591：OAuth 2.0 Dynamic Client Registration
• RFC 8693：OAuth 2.0 Token Exchange
• RFC 8628：OAuth 2.0 Device Authorization Grant
• RFC 9449：OAuth 2.0 Demonstrating Proof of Possession
• OpenID Connect Discovery 1.0

（完）