ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Scalar MCP 公共访问与 Passthrough 透传认证:让每个用户携带自己的 API 凭据连接 Agent

Scalar MCP 公共访问与 Passthrough 透传认证:让每个用户携带自己的 API 凭据连接 Agent Scalar MCP 公共访问与 Passthrough 透传认证让每个用户携带自己的 API 凭据连接 Agent【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar如果你的 API 本身已经要求认证、而你又希望任何人都能用他们自己的API Key 连接你通过 Scalar 发布的 MCP 服务器那么「公共访问 Passthrough 透传认证」就是最直接的方案。本文围绕 public-passthrough.md 展开完整讲解这种模式下 Scalar 的两层认证模型、Authorization等凭据头的转发边界、Dashboard 上的配置步骤以及 Claude Code 等客户端如何接入。读完你可以独立搭建一个访问全开放、凭据各自带的 MCP 服务器并清楚它与其他认证方案共享 Key、访问组的取舍。先说清楚MCP 服务器有两层独立认证要理解 Passthrough必须先理解 Scalar 对 MCP 服务器划分的两层互不干扰的认证详见 authentication/index.md谁被允许连接 MCP 服务器——这是 Scalar 侧的访问控制有三种取值Public任何人拿到 URL 即可连接无需 Scalar 登录、Team仅安装所属团队成员通过 Personal Access Token 或 OAuth、Access group允许名单中的邮箱/域名通过 OAuth 登录。服务器如何认证你的上游 API——这是按安装installation配置的上游认证有两种取值Global在安装上存储一份凭据每次调用都使用它调用方永远看不到 Key与Passthrough调用方自备凭据Scalar 在每次请求时将其转发给上游且不落盘存储。两层互相独立某个人可以因为 URL 公开而被允许连接第一层而服务器调用你的 API 时用的既可能是你存储的 Key也可能是他自己随请求带来的 Key第二层。Passthrough 正是第二层的一种具体实现。本文方案的适用场景「公共 MCP Passthrough 认证」适合这种形态的团队你的上游 API 已经强制要求认证每个调用者都有自己独立的 API Key你希望 MCP 服务器本身不做任何访问门槛谁拿到安装 URL 都能连接凭据校验完全交给你的 API 完成——Scalar 不做访问把关你的 API 把关。如果你的 API 是公开免费的或者你希望控制谁能连、但让用户各自带 Key请参考 customer-access.md访问组 OAuth如果你希望调用方完全不接触 Key、由服务器统一使用一份存储凭据请参考 shared-key.md。三者的关系在 authentication/index.md 的Pick a recipe小节中有清晰对照。工作原理这个方案由两个机制组合而成公共访问Public accessScalar 不需要登录即可触达 MCP 服务器。任何人拿到安装 URL 都能连接。注意这里的 MCP 指的是Installation MCP——它位于https://mcp.scalar.com/mcp/YOUR_INSTALL_ID与位于https://your-docs-domain/mcp的Docs MCP用于让 AI 客户端检索阅读你发布的文档是两套完全独立的端点。Installation MCP 默认是私有的只有在第一层认证设为 Public 后才对所有人开放详见 mcp.md。透传认证Passthrough auth调用方把自己的 API 凭据放进你指定的那个请求头Scalar 在每一次上游请求中把该请求头原样转发过去不存储。为什么公共安装才能用Authorization头因为服务器是公共的你可以直接指定标准的Authorization头来承载凭据。但在私有安装上进来的Authorization头携带的是 Scalar 的 OAuth Token用于验证谁允许连接这个头已经被占用。因此公共 MCP 服务器可以用Authorization做透传私有安装必须另选一个头例如X-API-Key。也就是说只有在公共安装上用Authorization做透传才是成立的。在 Dashboard 中完成配置整体流程如下在 Scalar Dashboard 的MCP区域操作进入Scalar Dashboard → MCP创建一个 MCP 服务器选择你想要暴露的 API将访问权限access设为Public将认证方式authentication设为Passthrough指定承载凭据的请求头例如Authorization。创建 MCP 服务器的完整前置步骤可以参考 mcp.md在MCP创建服务器 → 配置工具、选择 API 并决定暴露哪些端点 → 创建安装installation→ 配置认证。认证配置在 Dashboard 中按安装进行界面示意如下配置完成后把安装 URL 分享给使用方即可。客户端接入以 Claude Code 为例把安装 URL 分享出去让每个用户传入自己的凭据即可。使用 Claude Code 时在终端执行claude mcp add \ YOUR_MCP_SERVER_NAME \ https://mcp.scalar.com/mcp/YOUR_INSTALL_ID \ --header Authorization: Bearer YOUR_API_CREDENTIAL \ --transport http参数说明YOUR_MCP_SERVER_NAME你给这个 MCP 起的名字Claude Code 用它引用该服务器YOUR_INSTALL_ID为你的 MCP 服务器生成的安装 ID包含在安装 URL 中YOUR_API_CREDENTIAL你的上游 API 所期望的凭据内容例如Bearer super-secret-token--transport http使用流式 HTTP 传输Streamable HTTP。你选定的请求头会随每次 MCP 工具调用被转发给上游 API。由于凭据是调用方自己提供的Scalar 全程不存储、不落盘——这正是每个用户用自己的 Key的关键。转发边界只转发你指定的头Scalar 对上游请求的转发是有选择的只转发你在配置中指定的那一个或那几个请求头永不转发结构性请求头如 HTTP 协议层面的头以及 Scalar 内部使用的头。这意味着即便服务器是公共的调用方也无法通过自己塞一堆自定义头来顺带影响上游——能透传过去的只有你点名的那个凭据头。这条边界是 passthrough 方案安全性的基础。进一步延伸组合出更多形态Passthrough 不是孤立的它可以和其他访问控制组合出常见的生产形态面向所有客户共享一个 URL如果每个客户都有自己的 API Key可以把「访问组 Passthrough」组合起来——一个安装、一个 URL共享给所有客户每位客户携带自己的 Key同时用访问组把连接者限制在你的客户邮箱/域名范围内详见 customer-access.md客户完全不需要碰 Key改用 Global 认证shared-key.md为每个客户建一个安装、各存一份 Key再挂各自的访问组安装与访问组可通过 Scalar API 程序化创建适合按客户批量开通。相关文档authentication/index.md——两层认证模型与全部认证方案总览mcp.md——创建 MCP 服务器、Docs MCP 与 Installation MCP 的区别、工具配置customer-access.md——用访问组为透传服务器限定特定邮箱shared-key.md——所有人共用一份存储凭据的 Global 模式getting-started.md——从 OpenAPI 文档到 Agent 就绪的三步流程【免费下载链接】scalarScalar is an open-source API platform: Modern REST API Client Beautiful API References ✨ 1st-Class OpenAPI/Swagger Support项目地址: https://gitcode.com/GitHub_Trending/sc/scalar创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表