开发者扫描25个公开MCP服务器，发现多数缺失OAuth认证

MCP（Model Context Protocol）在纸面上有一套认证方案：OAuth 2.1 配合 PKCE、动态客户端注册、按 RFC 8707 定义的资源指示器。但在实践中，我不断遇到几乎没实现其中任何一项的服务器。于是我花了一周时间做了 patchbay audit——一个免费的 CLI，用来探测 MCP 服务器并报告发现的问题。然后我把它对准了能找到的 25 个公开端点。

扫描于 2026-11-02 进行，共 25 台服务器。它们全部公开列在社区目录或厂商文档中。URL 列表在 bench/mcp-sweep-targets.txt 里。

有三台服务器暴露出的问题，我认为属于严重级别。这三台都在任何公开文章点名之前，先收到了负责任披露邮件，并附带 90 天禁发期。其中一台（Chainflip 的 broker-as-a-service MCP）几小时内就回复了，附上他们公开的 AI 文档链接：broker 工具是刻意不做认证的，因为真正的价值转移由用户在链上签名，而不是由服务器端发起。公开即设计、有文档说明、权限范围正确。所以这一台从严重名单上撤下来了。

像 DeepWiki 和 Chainflip 这样"公开即设计"的服务器，现在被标记为 info 级别——属于公开只读或用户签名模式，而不是严重问题。这个区分比听起来更重要：我工具的第一个版本把 DeepWiki 判为"严重：无需认证"，那会让整篇文章在第一天就站不住脚。Chainflip 的回复是第二个教训：当一台服务器链接了 /.well-known/ai-catalog.json，或者有明确写着"无需认证"的 AI 文档页时，审计工具应该先读这些内容，然后降级。

patchbay audit <url> 会运行 13 项检查，大致分组如下：

服务器是否在没有凭证的情况下接受 tools/list？如果是，有没有工具名看起来是变更性的（create / delete / send / execute / start-...）？只有两者同时成立才判为严重。公开只读服务器被明确认定为一种合法模式。

如果服务器声明了 OAuth，它的工具是否声明了按工具划分的 scope？写工具和读工具是否共用同一个 scope（导致撤销写权限时连读也一起被撤销）？

目录模式下的检查，针对源文件中硬编码的 sk-... / ghp_... / AKIA... 模式（跳过测试夹具和示例模式）。远程模式下的检查，看端点是否接受明文 HTTP、是否接受伪造的 Origin 头、在 token 端点上是否把 localhost 和 127.0.0.1 一致对待。

如果探测什么都学不到（服务器在认证后面、用了未知传输方式，或者干脆不响应），我们会明确说出来，而不是返回"0 个发现，全部干净"。扫描各式各样的服务器时，这种"静默假阴性"陷阱是真实存在的风险。

架构刻意做得很无聊：packages/audit-core 里的检查函数内部零 I/O。探测阶段收集一个 TargetSnapshot 对象（服务器声明了哪些工具、接受哪些头、OAuth 元数据里有什么、目录里匹配到了哪些密钥正则）。检查函数是 (snapshot) => Finding[]。这样用夹具快照做单元测试就轻而易举，也能对缓存下来的扫描结果重跑检查，而不用重新探测网络。

npx -y @patchbay-nebius/agent audit https://mcp.example.com/mcp npx -y @patchbay-nebius/agent audit ./my-mcp-server --json npx -y @patchbay-nebius/agent audit ./my-mcp-server --sarif > out.sarif

--ci 会让它在出现严重 / 高危问题时以非零码退出，从而让你的 GitHub Action 构建失败。

MCP 2025-03-26 的 Streamable HTTP 规范还太新，大多数服务器实现还在追赶。多数服务器仍在交付 2024-11-05 规范和 Legacy SSE 传输。两者中，发现元数据都是可选项，所以那些已经有可用 OAuth 的厂商（因为它们本来就出于其他原因运行着受 OAuth 保护的 API：Linear、Notion、Supabase、Sentry）往往要求认证，但不一定提供 MCP 专属的发现文档。

我会担心的，是那些带有变更性工具、又没有文档说明为何公开的公开服务器。这些是创业公司和个人项目发布的 MCP 端点，看起来像只读的 wiki 查询，但工具列表里却包含 create_... 或 update_... 之类的工具，而且没有 ai-catalog 条目说明这是有意为之。发布它们的开发者可能根本没意识到这里没有认证关卡。

如果你现在正在构建 MCP 服务器，最快的改善点是：

OAuth 2.1 配合 PKCE 和资源指示器就是规范的全部；实现好这三样，你就领先这份名单上的大多数了。

npx -y @patchbay-nebius/agent audit <your-server-or-repo>

在 CI 里，把 examples/github-action/patchbay-audit.yml 复制到你自己的仓库，命名为 .github/workflows/patchbay-audit.yml。它会在每次 push 和 PR 时运行，出现严重或高危发现时构建失败，并把 SARIF 上传到 GitHub Code Scanning 标签页。

如果它标记了某个问题而你认为判断有误，带上输出开一个 issue。误报反馈是目前最有用的东西。第一版和第二版之间的严重级别重新校准，完全来自在已知良好的服务器上运行工具、找出它过于危言耸听的地方。

仓库：GodSmasher/patchbay。MIT 许可。无追踪、无后端、无账号。只是一个 CLI。