OpenConnector Deep Dive: Taking Apart 1.16M Lines of Code and 1,451 Providers

Background

While evaluating Agent technology, one question is unavoidable: when an Agent needs to operate external SaaS services (GitHub, Gmail, Slack, Notion...), where do the credentials live? Managing OAuth per-service yourself is painful, and handing everything to a cloud vendor feels risky. Pipedream and Composio are ready-made answers, but both are closed-source SaaS. So the author dissected OpenConnector (oomol-lab/open-connector), the loudest project in the open-source camp — cloned the source, read it line by line, and verified numbers via the GitHub API rather than repeating README claims.

Measured Numbers First

• 5,397 stars (launched 2026-06-29, two months old), 461 forks, only 4 open issues, 73 contributors, commits as of yesterday — genuinely active maintenance.
• Advertised as 1000+ providers / 10000+ actions. Source-level measurement: 1,451 provider directories and 10,925 defineProviderAction calls. The numbers are not exaggerated.
• But note the structure: of 1.168 million lines of TypeScript in src, the providers directory accounts for 96.9%. The actual gateway kernel is only ~36,000 lines. Most providers are shallow wrappers of 3 files.
• Auth distribution is sobering: 1,254 providers use api_key, only 58 use oauth2 (4%), plus 38 supporting both — so OAuth coverage is roughly 7%. "Managed OAuth" doesn't really exist for most providers; users still paste their own keys.

What It Gets Right: Credentials Never Enter the Agent Process

This is the soul of the project. When an Agent invokes a tool, it only sees connection metadata (id, authType, grantedScopes); full credentials with accessTokens are injected in-process via the executor context and never cross an HTTP boundary. Combined with redacted run logs and allow/block policies, this boundary design is correct and valuable. MCP integration is restrained: only five meta-tools (list_apps / list_connections / search_actions / get_action_guide / execute_action), with all 10,925 actions hidden behind execute_action — it won't blow up the agent's context.

Ten Hidden Reef Rocks (All Verified in Source)

The five harshest:

1. Zero auth by default, silently permissive. auth.ts:114 — without an adminToken configured, it directly returns authenticated: true. Combined with the Dockerfile's HOST=0.0.0.0 and compose's 3000:3000, following the README means an unauthenticated gateway listening on a host port. Not a bug — a choice of defaults. 2. Fail-open encryption. secret-codec.ts:39 — when reading credentials, it checks the prefix first; anything without the ciphertext prefix is returned as plaintext. Plaintext and ciphertext coexist in the same column with no "this instance must encrypt" assertion. Without an encryption key set, credentials are stored in plaintext with only a startup warning. 3. Hardcoded global KDF salt. Every deployment shares the same salt string, making cross-deployment precomputation theoretically feasible. Also, the Node-side scrypt and Worker-side PBKDF2 implementations produce incompatible ciphertexts (different prefixes) — migrating SQLite to D1 requires decrypt-and-re-encrypt, which the docs never mention. 4. POST /v1/proxy/:service is a big hole in the boundary. It accepts arbitrary endpoint/method/headers/body, injects credentials, and forwards — action-level scopes and allow/block policies have no effect on it (the docs' own words: "Action policy does not affect it"). This downgrades least privilege to "full proxy authority for whoever holds the key." Fully disabling it requires explicitly setting BLOCKED_PROXIES="*". 5. A static ADMIN_TOKEN is de facto root. No expiry, no rotation, no scoping — yet it controls credential writes and token issuance. One more warning sign: on 2026-08-27, Marketplace billing code entered the open-source trunk — today's optional add-on may be tomorrow's default path.

(The remaining five: globally shared idempotency keys, a three-hop MCP discovery chain, schemas abandoning type safety, 1,451 machine-generated providers with no compile-time quality guarantees, and JWT available only on the Node side — details in the full report.)

Competitive Landscape at a Glance

| Dimension | OpenConnector | Composio | Pipedream | Arcade | |---|---|---|---|---| | Open source | Apache-2.0, fully self-hostable | MIT core + managed commercial | Closed source, acquired by Workday | Closed source | | Strength | Highest self-hosting freedom, you own credentials | Most mature managed OAuth, 20k free calls/month | 3000+ apps, SOC2/HIPAA | Most refined auth model, SOC2 | | Weakness | Poor default security posture, only 7% OAuth | Heavy bills can spiral | Post-acquisition Agent direction unclear | Narrow integrations (44 apps) |

Bare MCP server comparison: with few services (≤3 major ones), just mount official MCP servers for best depth; only when services multiply do you need a gateway to consolidate the boundary — exactly OpenConnector's niche.

Three Business-Line Judgments

• Multi-agent research systems: best fit. Natural MCP integration; just accept the latency of the three-hop discovery chain.
• Quantitative trading: be cautious. The proxy hole + global idempotency namespace + static admin token can't support trading-grade permission auditing — and your brokers/data sources are probably not among the 1,451 providers anyway.
• C-end (consumer) products: not recommended. Zero auth + plaintext by default is far from consumer-grade compliance baselines. It's a self-hosted shell for experts, not a production-ready product out of the box.

Wrap-up

One sentence: "Credentials never enter the Agent process" is the right and valuable banner; but the default security posture is "if it runs, it's fine" — self-hosters must perform the coming-of-age ritual themselves.

If you adopt it, five hardening steps are non-negotiable: inject the encryption key from a vault, use a strong random ADMIN_TOKEN, issue per-caller runtime tokens, set BLOCKED_PROXIES="*", and remove port mappings so it only listens on the internal network.

The full report (architecture diagrams, source snippets, decision tree) is in the author's research archive. Discussion welcome. Source HEAD 908351b, data as of 2026-08-29.