API Authentication for MCP: API Keys, Bearer Tokens, and OAuth

API keys are usually simple integration credentials. Bearer tokens authorize whoever presents a valid token. OAuth adds delegated access, scopes, expiration, and an authorization server. The right choice depends on the API and the identity model behind the workflow.

Do not put secrets in tool names, descriptions, schemas, prompts, source files, or tool arguments. Use the narrowest credential that supports the workflow, keep tenant and role checks in the API, test failure paths as carefully as successful calls, and verify that credentials do not appear in outputs or logs.

What does API authentication for MCP mean?

API authentication for MCP is the process of proving that a request made through an MCP tool is allowed to call the underlying API. In an API-to-MCP setup, the MCP tool is the interface an AI client discovers, but the original API remains the source of truth for authentication and authorization.

That distinction matters because there can be two related security layers:

1. MCP endpoint authorization: whether an MCP client may connect to an HTTP MCP server. The official MCP authorization specification describes an optional OAuth-based authorization capability for HTTP transports.

2. Upstream API authentication: whether the original API accepts the credential used for a specific tool call. This is the focus of API key, Bearer token, and OAuth pass-through in an API-backed MCP server.

These layers should not be treated as interchangeable. A client may be allowed to connect to an MCP server and still lack permission to read a particular customer record. Conversely, a valid API key may authenticate an upstream request without expressing who is allowed to use the MCP endpoint. Define both boundaries explicitly when you design the system.

How authentication pass-through works

Authentication pass-through means that a credential is supplied at runtime and forwarded to the original API for the request. The MCP server does not need to turn a secret into a model-visible tool parameter, and the API does not need to be replaced with a second authorization system.

The request path looks like this:

MCP client
    |
    | tool call + runtime credential
    v
Hosted MCP server
    |
    | authenticated request to the original API
    v
Original API -> API authentication and authorization -> response

A safe pass-through flow normally follows these steps:

1. The user or calling client provides the credential through the runtime authentication flow.

2. The MCP client invokes a selected tool with business inputs, such as customer_id or invoice_status.

3. The MCP layer forwards the credential to the original API in the format that API expects.

4. The original API validates the credential, tenant, role, scope, record access, and requested action.

5. The MCP server returns the API result or a useful error without exposing the credential.

The tool input should contain the business data required for the operation, not an api_key, access_token, or client_secret field. Authentication belongs to the request context, not to the model's decision space.

With the authentication model, API keys, Bearer tokens, and OAuth credentials are passed to the original API during the request and are not stored by the platform. The platform also does not store activity data such as request headers or response content. The Trust page provides the broader explanation of data handling and security controls.

API keys vs. Bearer tokens vs. OAuth

The terms are related, but they describe different credential models. Use the model already supported by the original API unless you have a clear reason to change the API's identity architecture.

API keys

An API key is often the simplest choice for a server-to-server API or an integration that does not need an interactive user consent screen. The exact header name is API-specific; X-API-Key is common, but some APIs use another header or, less desirably, a query parameter.

Prefer an API key that is:

• limited to the required environment or tenant;

• restricted to the selected read or write operations;

• rotatable without downtime;

• excluded from URLs when the API supports a header; and

• easy to revoke if it is exposed.

An API key proves that a recognized credential was presented. It may not identify the individual person behind every request. If user-level attribution matters, use an identity-aware token or include a verified user context in the API's authorization design.

Bearer tokens

A Bearer token grants access to whoever possesses it, so the token itself must be protected like a password. Bearer tokens are commonly sent in the Authorization header:

Authorization: Bearer <runtime-access-token>

Do not assume that a token is valid simply because it is well-formed. The API should validate its signature or introspection result, issuer, audience, expiry, tenant, role, and scopes as applicable. A token can be authentic and still be unauthorized for a particular tool or record.

OAuth

OAuth is useful when access should be delegated by a user or organization rather than represented by one permanent integration secret. Scopes can limit what the access token may do, and short-lived tokens reduce the impact of exposure.

The exact OAuth responsibilities depend on the architecture. An authorization server may handle consent and token issuance, while the MCP client handles the user-facing sign-in flow. Refresh, expiry, scope selection, and revocation must follow the original API's requirements. The API-backed MCP layer should pass the resulting access token to the original API; it should not make the model responsible for exchanging or storing secrets.

Credential handling rules for MCP servers

Credential handling is where many technically correct integrations become unsafe. The following rules apply whether you build the server yourself or use a hosted API-to-MCP workflow.

Keep secrets out of the tool contract

Never put credentials in:

• tool names or descriptions;

• JSON schemas or example payloads;

• system prompts or saved instructions;

• OpenAPI descriptions or Postman examples that are shared publicly;

• source control, screenshots, issue tickets, or chat messages; or

• ordinary tool arguments that an AI model can inspect or repeat.

The schema should describe the action, not the secret needed to reach the API. For example, a get_invoice tool can require invoice_id; it should not ask the model to choose an Authorization header.

Pass only what the upstream request needs

Forward the required authentication material to the intended API origin and avoid copying unrelated headers. Do not forward browser cookies, internal tracing values, or credentials for a different service unless the integration explicitly requires them.

If the API only supports an API key in a query parameter, review the consequences carefully because URLs can be retained by proxies, browser history, or upstream infrastructure. A header is generally easier to handle safely when the API supports one.

Minimize observability exposure

Application logs, error messages, traces, and debugging output should redact API keys, access tokens, authorization headers, cookies, and OAuth client secrets. Do not return an upstream error that includes the full request URL or headers to the model.

Usage information can help teams inspect call status, duration, capability, source, and outbound response size without turning request headers or response content into stored activity data. Still test the complete path and check the logs available to your team for accidental secret leakage.

The API key management documentation and authentication documentation provide implementation guidance for credential handling and runtime authentication.

Least privilege for API-backed MCP tools

Least privilege means granting only the access required for a defined workflow. It applies to the credential, the endpoint, the data scope, and the time window—not only to the number of tools displayed in an MCP client.

Use this review sequence:

1. Start with the workflow. Write down the exact task, such as finding an unpaid invoice or updating a confirmed delivery date.

2. Select the smallest operation set. Expose only the reads and actions needed for that task.

3. Choose the narrowest credential. Prefer a read-only key or token for read-only workflows. Use separate credentials for production and staging.

4. Limit scope and audience. OAuth scopes, token audiences, tenant restrictions, and API roles should match the intended service.

5. Protect high-impact actions. Separate deletes, bulk updates, billing changes, permission changes, and external messages from ordinary reads.

6. Keep enforcement in the API. The API must check identity, tenant, role, record ownership, field access, and action permission on every request.

Removing an operation from the MCP tool list is useful allowlisting, but it is not a replacement for upstream authorization. If a broad API credential can call every route, hiding one route from the MCP interface does not make that credential least-privilege.

The authorization guide explains the separation between authentication and authorization. For an API-backed server, treat the original API's permission checks as the final enforcement boundary.

How to test MCP authentication before production

Authentication testing should cover both successful requests and predictable failures. Test through the same MCP client and hosted endpoint that production users will use; a direct API test alone does not confirm that the MCP layer forwards the credential correctly.

Use the Playground guide to inspect the generated tools, call them with realistic inputs, verify authentication, and review individual call behavior. When a test fails, the authentication errors troubleshooting guide can help separate an invalid credential from an API permission or configuration problem.

Before release, also check that:

• credentials are supplied at runtime rather than embedded in the tool definition;

• API keys and tokens are redacted in errors, traces, and logs;

• read-only credentials cannot perform write operations;

• expired and revoked credentials fail predictably;

• OAuth scopes are no broader than the workflow requires;

• tenant, role, record, and field authorization is enforced by the API; and

• rotation or revocation can be tested without rebuilding every tool.

A hosted authentication workflow with 0mcp

For teams that already have an authenticated API, 0mcp provides a hosted API-to-MCP workflow: import a supported Swagger, OpenAPI, or Postman definition, select the operations that should become MCP tools, refine their names and descriptions, and test the server in the Playground.

The authentication decision still belongs to the API owner. Configure the original API's API key, Bearer token, or OAuth flow for the calling MCP client, then verify that the selected operation receives the expected runtime credential. Do not hard-code a production secret into the imported definition or tool schema.

The resulting hosted MCP server keeps the API as the source of truth for tenant, role, record, and action authorization. The API-to-MCP workflow is a practical starting point when you want to expose a focused, authenticated capability surface without rebuilding the API's authorization rules inside every tool.

Common authentication mistakes

Treating a tool list as a permission system

Tool selection reduces the exposed capability surface, but it does not replace API authorization. Keep checks in the API and test them with different identities and scopes.

Giving every tool an administrator credential

An admin key may make early testing convenient, but it makes every exposed tool more dangerous. Create a credential for the smallest workflow and separate read access from write access.

Sending tokens as ordinary model input

A model should never decide which secret to use or see the raw value in a tool argument. Keep credentials in the client or request context and pass them at runtime.

Testing only the happy path

An authentication setup is not ready because one valid request succeeded. Test missing, expired, revoked, incorrectly scoped, and cross-tenant credentials as well.

Confusing upstream API auth with MCP endpoint auth

Document which identity protects the MCP connection and which identity authorizes the original API call. They may be implemented by different components and have different scopes.

Conclusion

Good API authentication for MCP keeps secrets out of the model-visible interface, passes credentials only when a request needs them, and lets the original API enforce identity and permissions. API keys, Bearer tokens, and OAuth can all work when their scope, lifetime, rotation, and failure behavior match the workflow.

Start with a narrow operation set, choose a least-privilege credential, test authentication and authorization together, and review data handling before production. For a hosted path, combine the API-to-MCP workflow with the authentication and Trust documentation so the generated MCP interface stays useful without weakening the API's existing security boundary.