MCP API key authentication is a static secret sent with every request to an MCP server, typically in an X-API-Key or Authorization: Bearer header. The server resolves the key to an identity, then enforces that identity's permissions on every tool call. It is the simplest way to authenticate an MCP client, and the most common for hosted servers.
Why Do So Many MCP Servers Use API Keys?
Because OAuth is hard. The MCP specification supports OAuth, and Cloudflare notes that the "complete MCP OAuth flow" involves the server acting as both an OAuth client to an upstream service and an OAuth provider to MCP clients — non-trivial to implement correctly (Cloudflare).
API keys sidestep that complexity. The server issues a key, the client sends it, the server maps it to a user. For single-tenant tools and developer-focused platforms, the tradeoff is worth it.
How Does the Key Flow Through a Request?
- The user creates a key in the product and gives it to the MCP client.
- The client attaches it as a header on every request.
- Server-side middleware resolves the key to a user before any tool runs.
- Tools read that identity and enforce ownership on every call.
The critical property is step 3: authentication happens before tool dispatch. A request with no key, or a revoked key, never reaches a tool. That is what makes per-tool ownership checks trustworthy — the identity is established first.
API Keys vs OAuth: Which Should You Use?
| API key | OAuth | |
|---|---|---|
| Setup | Paste a secret | Authorization flow |
| Best for | Developer tools, single-tenant servers | Multi-user, consent-driven access |
| Revocation | Delete the key | Revoke the grant |
| Token lifetime | Until revoked | Expires and refreshes |
| Flow complexity | Low | High |
The right answer is "whichever the server supports." If a server offers both, OAuth is generally better for user-facing consent; API keys are better for backend agents and developer tooling. Do not force an API-key server through an OAuth connector — it will fail.
What Makes an API Key Safe?
Scope and lifecycle, in that order.
Scope. A key should only unlock what its owner can access. Conbersa, for example, enforces the same ownership rules on MCP tools as in its web app: non-admin keys see only their own devices and sessions; admins see the organization. A key is not a master password.
Lifecycle. One key per integration. Create it, use it, revoke it when the integration ends. If a key appears in a log, screenshot, or commit, revoke and reissue rather than hoping.
Leaks are not hypothetical. GitGuardian's 2025 State of Secrets Sprawl detected 23,770,171 new hardcoded secrets in public GitHub repositories in 2024, a 25% year-over-year increase, and found that 70% of secrets leaked in 2022 were still valid (GitGuardian). Most leaked credentials are never revoked, which is exactly why lifecycle discipline matters.
OWASP's guidance on Excessive Agency is the deeper principle: minimize permissions, execute actions in the user's context, and require approval before high-impact actions (OWASP). A tightly scoped API key is how you enforce that at the credential layer.
What Are the Common Mistakes?
- Committing the key. The single most common leak. Configs with live keys belong in
.gitignoreor an environment variable. - Sharing one key across everything. Revoking it then breaks everything at once.
- Pasting the key into a prompt. Prompts can be logged; headers should not be.
- Assuming the key is read-only. If the server has write tools, the key can use them.
How Conbersa Uses API Keys
Every Conbersa MCP request authenticates with a per-user cb_live_... key, sent as X-API-Key or Authorization: Bearer. Create and revoke keys in the web app under Settings. There is no unauthenticated mode. See API keys for setup and MCP server security for the broader picture.