一个Agent连十几个MCP Server，每个都要独立OAuth和独立token，认证状态到底该怎么管？

从"令牌散落"到"授权域治理"：多MCP连接场景下的认证状态工程化路径

导语与摘要

Model Context Protocol（MCP）自2024年末由Anthropic公开以来，迅速成为Agent与外部工具、数据源之间的通用接口层。其早期版本聚焦于工具调用与资源读取，认证部分相对宽松；而2025年发布的规范修订中，MCP正式引入了基于OAuth 2.1的授权框架，把"远程MCP Server"的访问控制推向标准化。这一变化带来一个直接的工程后果：当单个Agent需要同时连接十几个甚至几十个MCP Server时，它面对的将不再是"一个token"，而是十几套彼此独立的授权服务器、客户端注册信息、作用域集合、刷新策略与撤销语义。

本文的核心主张是：多MCP场景下的认证问题，本质不是"令牌存储"问题，而是"授权域"（Authorization Domain）的状态治理问题。把每个MCP Server背后的授权服务器视为一个独立的授权域，围绕它建立生命周期状态机、隔离边界、同步协议与故障恢复策略，才能把散落的令牌收敛为可观测、可审计、可恢复的系统状态。本文评述：把OAuth令牌简单塞进一个共享KV或环境变量，是当前多数示例代码的默认做法，但它在多Server、多用户、多租户条件下会迅速失效——失效点不在加密，而在状态的所有权归属不清。

全文按"背景与问题定义 → 原理与技术路线 → 关键数据与案例 → 对比与局限 → 结论与展望"展开，中间穿插可操作的实现步骤、状态机设计、代码片段与对比表格。所有数据均标注来源，模拟数据单独注明。

目录

一、背景与问题定义：为什么"多Server"让认证突然变难

1.1 MCP的协议定位与授权演进

MCP定义了一套基于JSON-RPC的客户端—服务器交互模型，主机（Host）内的客户端（Client）与一个或多个服务器（Server）建立会话，服务器对外暴露工具（Tools）、资源（Resources）与提示（Prompts）三类能力。按照MCP规范文档的描述，协议本身刻意保持"传输无关"，可在stdio、HTTP+SSE、Streamable HTTP等传输之上运行。这种设计让本地进程内集成极为轻量，但也意味着认证责任被下推到了传输层与部署方。

2025年的规范修订明确引入了OAuth 2.1作为远程服务器的授权基线，要求MCP Server作为OAuth资源服务器（Resource Server），并支持受保护资源元数据（Protected Resource Metadata, RFC 9728）以声明其对应的授权服务器。同时，规范建议客户端使用动态客户端注册（RFC 7591）或客户端元数据文档（RFC 7591bis方向）来降低预注册成本。本文评述：这一演进的方向是正确的，但它把"一个Server一套授权"作为默认假设，而现实中的Agent往往同时面对十几个异构Server，每个Server的授权服务器、作用域命名、令牌有效期、刷新语义都可能不同，于是"默认假设"与"真实拓扑"之间出现了结构性缺口。

1.2 问题的准确定义

我们把问题形式化如下。设Agent需要连接服务器集合 S = {s₁, s₂, …, sₙ}，每个 sᵢ 关联一个授权域 Dᵢ = (issuerᵢ, client_idᵢ, scopesᵢ, token_endpointᵢ, revocation_endpointᵢ)。认证状态管理需要同时满足四类约束：

• 正确性：任一时刻，对 sᵢ 的请求必须携带属于 Dᵢ 且未过期的访问令牌；不得跨域混用。
• 隔离性：Dᵢ 的令牌泄露不得导致 Dⱼ 被攻破；多用户场景下，用户A的令牌不得被用户B的会话复用。
• 可恢复性：刷新失败、撤销、授权服务器抖动后，系统能在有限步内回到一致状态，且不产生令牌风暴。
• 可观测性：每个授权域的状态（有效、待刷新、失效、待重新授权）可被查询、审计与告警。

这四类约束在多Server条件下会相互冲突。例如，为提升可恢复性而引入的"集中刷新"会破坏隔离性；为强化隔离性而采用的"每域独立进程"，又会削弱可观测性。本文认为，冲突的根源在于缺少一个明确的"状态所有权"抽象——谁持有令牌、谁负责刷新、谁决定失效，必须在架构层面显式回答。

1.3 典型失败模式

在工程实践中，多MCP认证的失败往往不是"令牌被偷"，而是以下几类"状态错位"：

上述模式在单Server场景下几乎不可见，但在n≥10时出现概率显著上升。本文评述：这说明认证状态管理的复杂度并非随Server数量线性增长，而是随"授权域之间的交互面"超线性增长，因此必须用治理视角而非存储视角来设计。

二、原理与技术路线：以授权域为中心的认证状态模型

2.1 核心抽象：授权域与状态机

本文提出以"授权域"为第一类公民的建模方式。对每个 Dᵢ，维护一个显式状态机，状态集合为：UNREGISTERED → REGISTERED → AUTHORIZED → EXPIRING → REFRESHING → (AUTHORIZED | REAUTH_REQUIRED | REVOKED)。状态迁移由事件驱动：注册完成、授权码回调、令牌临近过期、刷新成功/失败、撤销通知。关键在于，每个状态迁移都必须落盘并带版本号，从而支持并发下的比较并交换（CAS）语义。

type AuthDomain struct {
    Issuer      string   // 授权服务器标识，必须与令牌iss一致
    ClientID    string
    Scopes      []string
    AccessToken string   // 加密存储
    RefreshToken string  // 轮换型需原子写回
    ExpiresAt   time.Time
    State       string   // 状态机当前态
    Version     uint64   // CAS版本号
    UpdatedAt   time.Time
}

// 刷新采用"单飞"语义：同一域同一时刻仅一个刷新在途
func (m *Manager) Refresh(ctx context.Context, d *AuthDomain) error {
    if !m.singleflight.TryAcquire(d.Issuer) {
        return m.waitForRefresh(ctx, d.Issuer)
    }
    defer m.singleflight.Release(d.Issuer)
    // 刷新前再次校验版本，避免覆盖他人已更新的令牌
    if cur, _ := m.store.Get(d.Issuer); cur.Version != d.Version {
        return ErrStaleVersion
    }
    // ... 调用 token_endpoint，成功后 CAS 写回
}

本文评述：单飞（singleflight）加CAS的组合，是解决"刷新风暴"与"轮换丢失"两个问题的关键。很多实现只做了单飞而忽略版本校验，在分布式部署下仍会出现旧令牌覆盖新令牌的竞态。

2.2 分层架构：控制面与数据面分离

建议将认证状态管理拆为控制面与数据面。控制面负责注册、授权流程编排、状态机推进、审计与告警；数据面负责在每次工具调用前注入令牌、处理401重试。两者通过一个带版本的令牌视图解耦，数据面只读，控制面只写。这样做的直接收益是：数据面可以水平扩展而不引入写竞争，控制面可以集中实施策略（如作用域最小化、刷新提前量）。

2.3 隔离边界的三种粒度

隔离性要求决定了存储与运行时的切分粒度。本文归纳为三种：

• 按授权域隔离：每个 Dᵢ 独立加密密钥与存储命名空间，适合单用户、多Server场景，实现成本最低。
• 按用户×授权域隔离：键为 (user_id, issuer)，适合多用户Agent平台，是多数SaaS的合理选择。
• 按租户×用户×授权域隔离：引入租户维度，适合企业级部署，需配合密钥管理服务（KMS）的分级密钥。

本文评述：隔离粒度不是越细越好。过细的粒度会让密钥轮换与审计查询的成本急剧上升，实践中应以"泄露影响半径"为决策依据——若某类Server承载高敏感数据（如代码仓库、财务系统），则单独提升其隔离等级，其余保持统一粒度。

2.4 可操作的实施步骤

下面给出一条从零到可用的落地路径，按顺序执行：

1. 盘点授权域：列出全部MCP Server，记录其issuer、是否支持RFC 9728元数据、是否支持动态注册、令牌有效期与是否轮换refresh token。产出授权域清单表。
2. 建立状态存储：选择支持CAS的存储（如带版本列的数据库或Redis+Lua），字段按2.1的结构设计，令牌字段加密。
3. 实现状态机：为每个域实现迁移函数，所有迁移写审计日志，包含旧态、新态、触发事件、版本号。
4. 接入授权流程：优先使用元数据发现 + 动态注册；对不支持动态注册的Server，预置client_id并纳入配置管理。
5. 实现刷新单飞与提前量：刷新提前量建议取令牌有效期的10%–20%，并设下限（如60秒），避免短寿命令牌频繁刷新。
6. 处理401与撤销：数据面收到401时，先触发一次受控刷新，仍失败则迁移到REAUTH_REQUIRED并通知上层。
7. 建立可观测性：为每个域暴露状态、剩余有效期、最近刷新结果、失败计数四类指标，配置告警阈值。

关于MCP授权规范的细节，可参考官方规范页面（modelcontextprotocol.io/specification）；OAuth 2.1草案见IETF（datatracker.ietf.org）；受保护资源元数据见RFC 9728（rfc-editor.org/rfc/rfc9728）。

三、关键数据与工程案例：状态机、并发与故障恢复

3.1 令牌生命周期的量化观察

不同授权服务器的令牌策略差异很大。以公开文档可查的几类典型配置为例：GitHub OAuth App的访问令牌在未启用过期时长期有效，启用后默认8小时；Google OAuth 2.0的访问令牌通常为3600秒，refresh token在测试模式下7天过期、生产模式长期有效但受撤销策略约束；Microsoft identity platform的访问令牌默认约1小时，refresh token有效期受条件访问策略影响。这些数值来自各平台官方文档，属于公开可查的配置事实，而非本文实验数据。

基于上述公开配置，可以做一个模拟推演（模拟数据，非实测）：假设Agent连接12个Server，其中6个令牌有效期3600秒、4个为8小时、2个长期有效。若刷新提前量取10%，则在稳态下每小时约有6次刷新事件，分布在6个不同授权域。若不做单飞，在并发10的负载下，同一域的并发刷新概率会显著上升。本文评述：这个推演说明，刷新风暴的风险主要来自"同一域的高并发"，而非"域的数量"，因此单飞应作为强制约束而非优化项。

3.2 并发刷新的竞态与修复

考虑两个协程同时读到过期令牌，均发起刷新。若授权服务器采用refresh token轮换（rotation），第一个请求成功并返回新refresh token，第二个请求携带旧refresh token将被拒绝，甚至可能触发整个令牌家族的撤销（部分实现的安全策略）。修复方式有三层：单飞锁、版本CAS、以及"刷新失败后先重读存储再决定是否重试"。

// 刷新失败后的安全重试：先重读，避免用旧refresh token二次冲击
func (m *Manager) safeRetry(ctx context.Context, issuer string) error {
    cur, err := m.store.Get(issuer)
    if err != nil { return err }
    if cur.State == StateAuthorized && time.Until(cur.ExpiresAt) > 0 {
        return nil // 他人已刷新成功，直接复用
    }
    return m.Refresh(ctx, cur)
}

本文评述：这段逻辑看似简单，却是很多线上事故的分水岭。缺少"先重读"的实现，会在轮换型refresh token下把一次并发退化为一次强制重新授权。

3.3 撤销传播与最终一致性

用户在某一Server侧撤销授权后，本地状态不会自动感知。可行的做法包括：订阅授权服务器的撤销事件（若支持）、在每次刷新失败时区分invalid_grant并迁移到REVOKED、以及定期做"轻量探活"（用最小作用域调用一个只读端点）。探活频率需权衡成本，建议对高敏感域每5–15分钟一次，普通域每小时一次。本文评述：探活不是万能的，它只能发现"已失效"，无法发现"权限被缩减"，后者需要依赖作用域校验或服务端返回的scope字段比对。

3.4 一个参考实现的结构

下面给出控制面的目录级结构，便于团队分工：

auth/
├── domain/          // 授权域模型与状态机
│   ├── model.go
│   └── fsm.go
├── registry/        // 元数据发现与动态注册
│   ├── discovery.go
│   └── dcr.go
├── store/           // 版本化存储与加密
│   ├── store.go
│   └── crypto.go
├── refresher/       // 单飞刷新与提前量
│   └── singleflight.go
├── audit/           // 审计日志
└── metrics/         // 指标与告警

关于OAuth安全最佳实践，可参考IETF的OAuth 2.0 Security Best Current Practice（draft-ietf-oauth-security-topics）；动态注册见RFC 7591（rfc-editor.org/rfc/rfc7591）。

四、对比与局限：五种主流方案的边界条件

4.1 方案对比

本文评述：没有一种方案在所有维度占优。集中式令牌服务的可恢复性强，但隔离性依赖实现质量；Sidecar隔离性最好，但运维复杂度高。授权域治理模型的优势在于把"隔离"与"可恢复"解耦到不同层次——隔离由存储命名空间与密钥保证，可恢复由状态机与单飞保证，二者互不牵制。

4.2 局限与未解问题

本文模型仍有若干边界。其一，对不支持元数据发现与动态注册的Server，仍需人工配置，治理收益打折。其二，跨授权域的作用域合并（例如一个任务需要同时访问两个Server的关联资源）目前缺少标准化的"授权聚合"机制，实践中只能由Agent编排层做串行授权。其三，撤销传播的实时性受限于授权服务器能力，最终一致性窗口难以压缩到秒级。其四，多租户下的密钥轮换与审计留存成本较高，需要与合规要求对齐。本文评述：这些局限不是模型缺陷，而是OAuth生态本身的能力边界，工程上应通过"分级治理"而非"一刀切"来应对。

五、结论与展望：从令牌管理到授权可观测性

回到最初的问题：一个Agent连十几个MCP Server，认证状态到底该怎么管？本文的答案是——不要把它当作"存token"，而要当作"治理授权域"。具体而言：以授权域为键建立显式状态机，用版本化存储支撑并发，用单飞与提前量控制刷新节奏，用分层架构分离控制面与数据面，用分级隔离控制泄露半径，用审计与指标实现可观测性。这条主线的价值在于，它把散落在各处的令牌收敛为可推理、可验证的系统状态。

展望未来，三个方向值得关注。第一，MCP规范层面可能出现"授权聚合"或"委托授权"的扩展，降低多域编排成本；第二，OAuth生态中关于令牌绑定（如DPoP, RFC 9449）与细粒度授权（如Rich Authorization Requests, RFC 9396）的实践，会进一步改变多Server场景的威胁模型；第三，Agent运行时的"授权可观测性"可能成为独立的基础设施层，类似今天的可观测性平台。本文评述：无论标准如何演进，"状态所有权清晰"这一原则不会过时，它是一切上层优化的前提。

最后给出一个可立即执行的检查清单：是否为每个授权域维护了独立状态？是否所有状态迁移都带版本与审计？刷新是否单飞且带提前量？401与invalid_grant是否被区分处理？是否对高敏感域做了更细的隔离与更频的探活？若这五问都能回答"是"，多MCP认证状态管理的基本盘就已经稳了。

六、主要参考文献与资料