MCP OAuth vs API keys: authentication and access checks

You have entered an MCP endpoint, but access requires authentication. The next step is to use the authentication method documented for that server. An OAuth grant, a provider-issued API key and an environment variable passed to a local process have different roles. This guide separates connection setup, account selection and permissions, then gives you a small verification workflow you can repeat in your own environment.

Identify the documented authentication method

MCP protocol revision 2025-11-25 describes OAuth-based authorization for HTTP connections. Authorization is optional: a public read service may be available without signing in. With stdio, credentials are generally provided through the process environment. That does not establish a universal variable name; each server documents its own. Check both the server documentation and your client’s setup instructions before adding any credential.

An API key may let a local server call another service. That is a second connection: client to MCP server, then MCP server to data provider. Record which connection produced the error. For local values, the environment variables guide explains the difference between a process environment and client-specific placeholders. A variable with the right-looking name is not evidence that the intended process received it.

Set up an OAuth connection with a clear account choice

Start authentication through the client’s documented workflow. In the browser, inspect the provider, selected account and requested permissions. After granting access, the workflow must return to the client. Successful sign-in does not prove access to the project you need. A private document in a different workspace may remain unavailable. Before trying a broader request, establish which workspace the connection is actually using.

Tokens have an intended recipient. Do not copy a credential from another application into an MCP header as a guess. The official security documentation specifically addresses the dangers of passing through tokens without appropriate validation. Follow the documented authorization flow instead. For a useful test record, write down the authentication method and permission names; the secret value itself is not needed to explain what you checked.

Limit and record the first operation

1. Choose a test project and a known, uncritical record. Write down its identifier and expected read result.

2. Check the signed-in account and access to that specific project. Compare the requested permissions with the operation you plan.

3. Connect the server and inspect its tools. Then perform exactly one suitable read operation.

4. Compare the response with the known record. Record time, client version and outcome, plus how to revoke the grant later.

A useful test answers a concrete question, such as whether the known note can be read from the correct workspace. “Connected” alone does not answer it. Repeat the operation after an account change. If several accounts are available in the browser, explicitly record which one the client uses. This exposes an unintended workspace before you begin a larger query and makes a later handover easier to verify.

Distinguish 401, 403 and signing in again

In the OAuth workflow, 401 indicates missing or unaccepted authorization. A 403 may involve insufficient permissions. Also read the server’s message: a status code does not identify every underlying cause. The HTTP error guide covers the next checks. The Notion guide gives a provider-specific workflow with workspace verification.

Does every MCP server need an API key?

No. Public access, OAuth connections and provider-specific credentials are different possibilities.

Is env a kind of OAuth?

No. It passes values to a process; it does not describe an OAuth authorization flow.

Does signing in grant access to every project?

No. Accounts, grants and permissions may still restrict access.

Should I generate a new key for every error?

First inspect the intended service, error and permissions. A new key does not correct a wrong endpoint or project.

Official documentation checked on 1 October 2026. Examples and checklists are editorial suggestions.

1. MCP authorization
   Show retrieval command

   curl -s https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
2. MCP security best practices
   Show retrieval command

   curl -s https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices
3. MCP transports
   Show retrieval command

   curl -s https://modelcontextprotocol.io/specification/2025-11-25/basic/transports

All posts