OpenConnector架构深度解析网关如何隔离凭据并执行1000 Provider Action【免费下载链接】open-connectorOpen-source auth gateway connecting 1000 SaaS providers to AI agents through SDK, CLI, MCP, HTTP, and OpenAPI.项目地址: https://gitcode.com/gh_mirrors/op/open-connectorOpenConnector 是一个开源连接器网关Auth Gateway让 AI Agent 通过 SDK、CLI、MCP、HTTP 和 OpenAPI 五种方式安全接入 1000 SaaS 服务商的 10,000 预构建 Action。它的核心价值在于凭据隔离服务商的 API Key 和 OAuth Token 永远留在网关内部Agent 只拿到元数据、安全的账户标签和执行结果——既能让 Agent 真正用上用户的 Gmail、GitHub、Notion 等应用又不必把敏感凭据交给 Agent 进程。全景图一条请求要穿过哪几层理解这个架构先记住一句话Agent 不直接碰服务商一切经过网关。一次 Action 调用的链路如下AI Agent / 应用 │ SDK / CLI / MCP / HTTP ▼ OpenConnector 网关 ├─ ① 目录查找Action 是否存在 ├─ ② 策略检查该调用方被允许执行吗 ├─ ③ 连接解析选用哪个用户连接凭据在此解锁不离开网关 ├─ ④ 懒加载执行器按需加载对应 Provider 的执行代码 ├─ ⑤ 守卫网络请求防 SSRF、防凭据外泄 └─ ⑥ 审计日志记录脱敏的运行摘要 ▼ 1,000 ProviderGmail、GitHub、Notion …对应的模块划分非常清晰层职责关键位置接入层HTTP API、MCP 端点、OpenAPI 文档src/server/api/runtime-api.ts、src/mcp.ts执行边界策略判定 → 连接解析 → 执行 → 审计src/server/actions/action-runner.ts凭据边界加密存储、按需解锁src/server/secrets/、src/connection-service.ts目录与契约Provider 目录、Action Schemasrc/core/catalog.ts、docs/catalog-format.mdProvider 执行器每个服务商一个目录含定义、Action、执行器src/providers/github/仓库中实际收录了1452 个 Provider 目录每个目录结构统一definition.ts服务商元数据与认证方式、actions.tsAction 契约、executors.ts执行逻辑这种一致性正是1000 Provider可维护性的来源。凭据隔离API Key 和 OAuth Token 如何不泄漏这是整个架构最关键的设计靠三个机制配合完成。1. 存储层AES-256-GCM 加密落库凭据从不以明文躺在磁盘上。网关使用scrypt派生密钥、AES-256-GCM 加密每一条凭据记录密文带enc:v1:前缀自识别解密时先校验认证标签——实现见 secret-codec.ts。配置方式很简单设置环境变量OOMOL_CONNECT_ENCRYPTION_KEY即可启用详见 docs/credentials.md未配置密钥时运行时会打印启动警告并以明文模式工作——这是留给本地开发的逃生通道生产环境必须关闭。支持四种认证形态no_auth免认证如 HackerNews、api_key、custom_credential任意自定义字段、oauth2完整授权码流程 自动令牌刷新实现在 src/oauth/oauth-credential-refresh-service.ts。字段契约由每个 Provider 的auth元数据声明未知字段直接拒绝而非静默存储保证凭据表单与定义漂移即失败。2. 运行层凭据只以回调形式注入注意 action-runner.ts 中构建执行上下文的细节传给 Provider 执行器的不是一个凭据对象而是一个getCredential回调函数。也就是说执行器需要凭据时才在网关进程内惰性解锁凭据值从头到尾不出网关边界Agent 侧只能看到连接别名 安全账户标签如 Gmail 账号名拿不到任何 Token。3. 网络层守卫请求拦截凭据外泄即使执行器逻辑有漏洞src/core/guarded-fetch.ts 也会在出网前兜底防 SSRF请求前校验 DNS 解析地址拦截回环、内网RFC 1918、链路本地与云元数据地址防止恶意 URL 把凭据导向内网防凭据外泄当 3xx 重定向跨源时自动剥离 40 种凭据头Authorization、X-Api-Key、各服务商私有认证头等跨源跳转无法顺走服务商凭据重定向限跳最多 20 跳与 fetch 规范默认行为对齐。同样的守卫思路也覆盖了 WebSocketguarded-websocket.ts与 IP 分类request.ts。Action 执行管线从调用到审计的完整闭环所有调用方HTTP、MCP、未来本地调用共用同一个执行边界ActionRunner流程保证任何入口行为一致查目录Action 不存在直接拒绝并记unknown_action警告策略判定先执行 Action 级 allow/block 策略再做连接级判定——策略服务见 src/core/action-policy.ts连接解析选定连接后若 Action 不可本地执行或属于 Marketplace 托管类型走对应分支否则懒加载执行器providerLoader.loadActionExecutor——1452 个 Provider 的代码按需载入冷启动不背全量包袱输入校验 执行src/core/execution.ts 先用 JSON Schema 校验输入再调用执行器审计落库每次运行生成脱敏摘要summarizeForRunLog写入 Run Log包含执行 ID、耗时、策略判定、输入/输出摘要Web 控制台可直接复核最近运行。运行时令牌给 Agent 发有限权限的钥匙网关通过运行时令牌Runtime Token把权限收紧到调用方粒度每个令牌可以限定可执行的 Action 范围与可用的连接范围。生产部署中建议给每个 Agent/应用单独签发令牌而不是共用一个全权限凭据——控制台即可创建配套端点文档在 docs/runtime-api.md。多种接入方式同一份契约同一个 Action 契约ID、Schema、所需 Scope在所有接入方式中保持一致SDKTypeScript 薄 HTTP 客户端适合应用代码直连oo CLI本地 Agent 中继可搜索、查看并执行 ActionMCP/mcp端点暴露给支持 MCP 的 Agent 宿主HTTP / OpenAPI直接调/v1/actions/*或查看自动生成的/openapi.json。部署形态同样灵活本地 Docker/NodeSQLite 或 PostgreSQL、Fly.io、CloudflareWorkers D1 R2或托管运行时。同一套契约意味着从开源自建到商业托管可以平滑迁移Cloudflare 部署的完整步骤见 docs/cloudflare.md。验证你的网关看运行概览部署完成后Overview 页面是验证架构各层是否健康的最快方式运行时就绪状态、可用 Provider 数、可执行 Action 数、最近失败、工具调用趋势一览无余——目录层、执行层、审计层是否正常工作一张图就能判断。想读源码从这 5 个文件开始想理解什么读这里执行边界与审计闭环src/server/actions/action-runner.ts凭据加解密src/server/secrets/secret-codec.ts出网安全守卫src/core/guarded-fetch.tsAction 契约类型定义src/core/types.ts一个完整 Provider 示例src/providers/github/总结为什么说它是凭据隔离而不只是API 聚合很多连接器项目本质是 API 转发器而 OpenConnector 架构真正的差异化在于边界感凭据边界加密存储 回调注入 出网守卫三层防御、权限边界运行时令牌 Action/连接级策略、审计边界每次执行必留脱敏日志。对新手而言记住这张心智图即可——Agent 拿着有限权限的钥匙来敲门网关验明正身、按需开锁、看着它干活、记好台账而真正的钥匙串从不离开钥匙柜。这套设计让团队可以放心地把 Gmail、GitHub、Notion 等应用交给 AI Agent 使用同时把敏感凭据留在可审计的运行时之内。【免费下载链接】open-connectorOpen-source auth gateway connecting 1000 SaaS providers to AI agents through SDK, CLI, MCP, HTTP, and OpenAPI.项目地址: https://gitcode.com/gh_mirrors/op/open-connector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考