AI 插件开发工具插件系统【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址https://gitcode.com/GitHub_Trending/cl/claude-plugins-official点击查看免费下载在 Claude 生态中构建 MCP Server 时鉴权Auth往往是决定本地够用、远程必须的分水岭OAuth 重定向、Token 存储与刷新只有在存在真实托管端点的场景下才能干净工作。本文基于 mcp-server-dev 插件的核心参考文档 auth.md系统梳理 Claude MCP 客户端实际支持的鉴权类型、CIMD 与 DCR 两代 OAuth 2.0 流程的落地责任清单、三级部署策略、Token 存储与受众校验规范并给出modelcontextprotocol/sdk现成助手mcpAuthRouter/bearerAuth/proxyProvider的使用指引。读完本文你将能根据上游服务的鉴权形态为你的 MCP Server 选择并实现一套可被 Claude 客户端正确识别、且符合 MCP 规范spec 2025-11-25的鉴权方案。为什么鉴权是远程化的核心驱动力本地 MCP Server 通过 stdio 与宿主进程通信鉴权可以退化为简单的 API Key 读取而一旦服务器需要被远程调用OAuth 重定向、Token 存储和刷新这些环节就必须有真实、可访问的托管端点来承接。这正是 auth.md 开篇给出的核心判断鉴权是大多数人即使本地方案更简单也仍然需要远程服务器的根本原因。在 build-mcp-server 的 Phase 1 用例问询中上游服务使用什么鉴权是决定部署形态的关键问题之一上游为 None / API Key → 流程直接走本地或远程均可上游为 OAuth 2.0 → 必须选择远程 HTTP 服务器并实现CIMD首选或 DCR支持。Claude 特有的鉴权类型支持矩阵Claude 的 MCP 客户端只支持一组特定类型的鉴权——并非所有符合规范的流程都能直接工作。下表总结了支持情况完整参考见 Claude 官方连接器文档的 authentication 章节版本敏感声明记录于 versions.md类型说明oauth_dcr支持。对于高流量目录条目优先选择 CIMD 或 Anthropic 托管的凭据——DCR 会在每次新连接时注册一个新客户端oauth_cimd支持对目录条目推荐优先于 DCRoauth_anthropic_creds合作方向 Anthropic 提供client_id/client_secret用户同意后生效。联系mcp-reviewanthropic.comcustom_connection用户连接时提供 URL/凭据Snowflake 风格。联系mcp-reviewanthropic.comnone无鉴权明确不支持的类型用户直接粘贴的 Bearer Tokenstatic_bearer无用户同意的纯机器对机器client_credentials授权。回调 URL单一、覆盖所有场景https://claude.ai/api/mcp/auth_callback这一单一回调地址意味着无论使用哪种受支持的 OAuth 变体授权完成后宿主都会回到同一个端点服务器端无需为不同入口维护多条回调路径。三级鉴权部署策略Tier 1无鉴权 / 静态 API Key服务器从环境变量读取密钥用户安装时一次性提供之后即可使用。这是最简单的方案官方文档给出的核心代码片段如下const apiKey process.env.UPSTREAM_API_KEY; if (!apiKey) throw new Error(UPSTREAM_API_KEY not set);它同时适用于本地 stdio、MCPB 打包与远程服务器。如果你的需求止步于此可以直接采用无需进入 OAuth 复杂度。与之配套的安全基线是密钥一律来自环境变量绝不硬编码参见 remote-http-scaffold.md 的部署清单。Tier 2基于 CIMD 的 OAuth 2.0规范首选Client ID Metadata DocumentCIMD是 MCP 规范 2025-11-25 版本升级为 SHOULD推荐的机制。其核心思想是MCP 宿主将其客户端元数据发布在一个 HTTPS URL 上并直接把这个 URL 当作client_id。你的授权服务器在授权时获取该文档、校验其合法性然后继续标准的授权码流程。整个过程不需要注册端点也不需要存储客户端记录。作为服务器授权服务器方需要承担的责任清单在/.well-known/oauth-authorization-server提供 OAuth Authorization Server MetadataRFC 8414并声明client_id_metadata_document_supported: true提供一个指向1的 MCP 保护资源元数据文档授权时刻将client_id视为 HTTPS URL 去获取校验返回的客户端元数据再继续流程对进入/mcp的请求校验 Bearer Token。流程示意┌─────────┐ client_idhttps://... ┌──────────────┐ upstream OAuth ┌──────────┐ │ MCP host│ ────────────────────── │ Your MCP srv │ ───────────────── │ Upstream │ └─────────┘ ─── bearer token ───── └──────────────┘ ── access token ──└──────────┘Tier 3基于 DCR 的 OAuth 2.0兼容性回退Dynamic Client RegistrationDCR在规范 2025-11-25 中被降级为 MAY作为向后兼容的回退方案。流程为宿主发现你的registration_endpointPOST 自己的元数据完成客户端注册拿到client_id再执行授权码流程。如果你的服务器需要支持尚未迁移到 CIMD 的宿主则实现 DCR。责任清单与 CIMD 基本一致区别在于不是去获取client_idURL而是运行一个注册端点来存储客户端记录。客户端优先级顺序预注册pre-registered→ CIMD若授权服务器声明client_id_metadata_document_supported→ DCR若授权服务器提供registration_endpoint→ 提示用户手动配置。这条优先级链的实践含义是你的授权服务器可以同时声明 CIMD 与 DCR 能力让不同成熟度的宿主各自走自己能走通的路径最终才落到人工配置兜底。托管服务商的内建支持文档明确指出多个专注于 MCP 的托管服务商已经替你处理了 OAuth 管道——你只需实现工具逻辑他们运行授权服务器。若用户没有强烈的托管偏好这是最快获得一个带 OAuth 保护的可用服务器的路径能力细节以各家最新文档为准。仓库内与之对应的落地佐证是 Cloudflare 路径deploy-cloudflare-workers.md 提到 Cloudflare 的cloudflare/workers-oauth-provider是一个即插即用组件负责授权服务器一侧的 CIMD/DCR 端点、Token 签发与同意 UI并包装McpAgent对/mcp做 Token 校验其模板cloudflare/ai/demos/remote-mcp-github-oauth展示了完整接线方式。这印证了你写工具逻辑、平台跑授权服务器的分工模式确实存在并可落地。本地服务器与 OAuth 的兼容性问题本地 stdio 服务器理论上可以做 OAuth打开浏览器、在 localhost 端口捕获重定向、把 Token 存入 OS 钥匙串但很脆弱在无头/远程环境中会失效每个用户都要重复一遍授权舞蹈没有集中的 Token 刷新与吊销机制。因此文档给出的明确建议是如果必须 OAuth尽量选择远程 HTTP。若实在要本地 OAuth组合modelcontextprotocol/sdk提供了 localhost 重定向助手且应使用 MCPB 打包至少保证运行时的可预测性MCPB 的打包与清单细节见 build-mcpb 及 manifest-schema.md。Token 存储策略不同部署形态对应不同的 Token 存放位置部署形态Token 存放位置远程、无状态不存储——宿主每个请求都携带 Bearer远程、有状态以 MCP 会话 ID 为键的会话存储Redis 等MCPB / 本地OS 钥匙串Node 用keytarPython 用keyring。绝不以明文写盘与 MCPB 侧的安全基线相互印证local-security.md 同样强调绝不以明文文件存密钥并指出如果宿主的钥匙串集成不够用就自行使用keytar/keyring。也就是说明文写盘在整套插件的安全要求中是被一致禁止的红线。Token 受众校验规范 MUST与转发禁令校验这是否是一个合法 Bearer Token并不够。规范要求进一步校验这个 Token 是否为这台服务器铸造的——即 RFC 8707 的 audience受众校验。即使签名校验通过一个签发给api.other-service.com的 Token 也必须被拒绝。与此配套的一条硬性规则Token 透传被明确禁止。不要接收一个 Token 后再原样转发给上游。如果你的服务器需要调用其他服务应进行 Token 交换或使用自己的凭据。从实现角度这两条规则意味着校验逻辑不能只做签名验证还要比对aud声明与自身标识代理上游调用时不能简单地把客户端传入的 Token 直接附加上游请求头而要走授权码交换或服务端自有凭据路径。用 SDK 助手落地不要手搓modelcontextprotocol/sdk/server/auth开箱提供了三件套文档强调如果你要从零接线鉴权先看这些mcpAuthRouter()—— 覆盖完整 OAuth 授权服务器表面的 Express 路由metadata、authorize、token 端点bearerAuth—— 中间件用你的 verifier 校验 Bearer TokenproxyProvider—— 将鉴权转发给上游 IdP。配合 TypeScript SDK 的远程服务器脚手架remote-http-scaffold.md典型落地路径是mcpAuthRouter()挂载授权端点、bearerAuth保护/mcp入口、proxyProvider对接上游授权服务从而把上面 Tier 2/Tier 3 的责任清单逐项兑现而不是从 RFC 层面重新实现一遍 OAuth。落地顺序建议综合 build-mcp-server 的决策矩阵与本文的鉴权内容推荐按以下顺序推进判断上游鉴权形态None/API Key 直接走 Tier 1OAuth 2.0 进入下一步选择部署形态远程 HTTP 优先推荐 Cloudflare Workers 或可移植的 Express/FastMCP 脚手架只有必须触碰本地环境才考虑 MCPB选择 OAuth 变体优先实现 CIMDclient_id_metadata_document_supported: true同时按需声明 DCR 的registration_endpoint以兼容旧宿主用 SDK 助手组装mcpAuthRouterbearerAuthproxyProvider再按 RFC 8414 元数据、RFC 8707 受众校验、Token 存储策略逐项对照检查测试与发布在 Claude 设置中添加自定义连接器Settings → Connectors实测再按目录提交与审查要求references/auth.md之外详见 build-mcp-server/SKILL.md 的 Phase 6提交到 Anthropic 目录。整个过程中需要警惕的底线有三条Token 透传禁止、明文写盘禁止、受众校验不可省略——这三点分别对应规范 MUST、安全基线与防跨服务 Token 滥用也是评审中最容易被挑出的硬伤。赞分享AI 插件开发工具插件系统【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址https://gitcode.com/GitHub_Trending/cl/claude-plugins-official点击查看免费下载相关推荐基于 mcp-use 构建 Auth0 直验型 MCP 服务器从 JWKS 本地验证 Access Token 到工具鉴权基于 mcp use 构建 Auth0 直验型 MCP 服务器从 JWKS 本地验证 Access Token 到工具鉴权 本文以 mcp useTypeS后端MCP 服务MCP ClientsAI Agent人工智能Velero 本地部署实战对象存储选型、卷快照方案与 Air-Gapped 环境完整落地指南Velero 本地部署实战对象存储选型、卷快照方案与 Air Gapped 环境完整落地指南 本文基于 Velero 官方文档 site/content/do后端API网关大模型AI 应用Sa-Token 前后端分离鉴权实战无 Cookie 模式下 Token 的下发、存储与提交Sa Token 前后端分离鉴权实战无 Cookie 模式下 Token 的下发、存储与提交 在 App、小程序、以及前后端分离的 Web 场景中终端往往不后端认证鉴权单点登录上一篇ioredis负载均衡客户端分片与数据分布策略下一篇终极指南SDWebImage请求修改器让HTTP请求定制化不再困难创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考