How does MCP authentication work?
By Identra · Updated
MCP authentication verifies the credentials used to access a Model Context Protocol server. For protected HTTP connections, MCP defines an OAuth-based authorization framework that lets clients obtain access tokens and servers validate whether those tokens permit access.
Key numbers
- 1,862 MCP servers were found exposed directly to the internet in a July 2025 scan (Knostic, 2025)
- 119 of 119 exposed MCP servers sampled for manual verification allowed access to tool listings without any authentication (Knostic, 2025)
What does MCP authentication actually prove?
The Model Context Protocol connects AI applications to tools and data. A server might expose repository search, customer records, or infrastructure operations. Authentication checks credentials at that boundary. Authorization decides which resources and actions the caller may access.
OAuth is an authorization framework, not a universal proof of human or agent identity. A valid bearer token establishes that the caller possesses an accepted credential. It does not prove that the current action matches the user's intent, that the client software is trustworthy, or that a particular agent run has been independently identified.
Keep the user, client application, agent, and downstream account distinct in access records. A shared service credential can make unrelated requests appear to come from the same principal. That limits accountability even when token validation works correctly.
How does authentication work for remote MCP servers?
For protected HTTP connections, the MCP server acts as an OAuth resource server. The client discovers the authorization server through protected resource metadata. In an interactive authorization flow, the user signs in and grants access as required, then the client obtains a token for the MCP server.
The client uses PKCE to protect the authorization code exchange and includes a resource parameter identifying the target server. It sends the access token in the Authorization header. The server validates the token and its intended audience before processing protected requests. Authorization is optional at the protocol level. These details follow the MCP authorization specification.
An enterprise should still require access controls for servers exposing private data or privileged actions. Public documentation search and production database administration have different access requirements. Choose the policy from the resource's sensitivity, rather than assuming every MCP endpoint needs the same treatment.
How are remote HTTP and local STDIO connections different?
The HTTP authorization framework does not govern local STDIO connections. For STDIO, the specification recommends retrieving credentials from the environment. Local execution therefore needs separate attention to process permissions, credential handling, and which software may launch the server.
A local MCP server may also authenticate to a remote business API. That downstream credential is a separate security boundary from the local client-to-server connection. Apply secrets management practices to both the credential and the process that can read it.
Client to protected HTTP MCP server
- Access boundary
- Access token accepted by the MCP server
- Practical control
- Validate tokens and enforce resource permissions
Client to local STDIO MCP server
- Access boundary
- Ability to launch and communicate with a local process
- Practical control
- Restrict launch configuration, process access, and inherited secrets
MCP server to a business API
- Access boundary
- Credential accepted by the downstream service
- Practical control
- Use appropriately scoped downstream credentials
What does secure MCP access look like in an enterprise?
Consider a support assistant connected to a customer-records MCP server. An employee authorizes the assistant to read cases assigned to their team. The server validates the token, then checks the employee's access to the requested customer record before returning it.
A valid token should not automatically permit searching every customer, exporting attachments, or changing billing details. The server must enforce those boundaries against the actual request. If billing changes are needed, treat them as a separate permission with an explicit approval requirement.
If the MCP server calls a downstream customer-management API, use a separately issued token intended for that API. MCP prohibits passing through the client's MCP access token. This separation helps prevent the confused deputy problem, where an intermediary misuses its authority for another caller. See the official MCP security guidance.
Record the requesting user, client, target record, operation, and outcome. That gives an investigator evidence of whose authority was used and what happened without storing raw credentials.
How should security teams defend MCP authentication?
Start with an inventory of servers, clients, owners, and downstream permissions. Apply least privilege at the tool and data level, then test that denied actions actually fail. A successful login is only the beginning of an access-control test.
- Require authentication for sensitive remote endpoints and use HTTPS. Review the authorization servers and redirect destinations that clients are allowed to trust.
- Validate token authenticity, issuer, expiry, and intended audience using the issuer's supported mechanism. Reject missing, invalid, expired, and wrong-audience tokens.
- Enforce authorization for each requested action and resource. Test cross-team, cross-user, and cross-tenant access attempts wherever those boundaries exist.
- Keep downstream credentials separate. Avoid shared administrator credentials when a narrower delegated or service identity can do the job.
- Store tokens outside prompts, URLs, source repositories, and ordinary application logs. Limit token lifetime and verify the actual revocation behavior of the deployment.
- For local servers, review package provenance, executable paths, launch arguments, and inherited environment variables. Give the process only the secrets and filesystem access it needs.
- Exercise offboarding and incident response. Confirm that removing a grant or disabling an account prevents further access as expected, including access through cached credentials.
What risks remain after authentication succeeds?
Authentication does not prevent prompt injection. An authenticated assistant can still follow malicious instructions embedded in a document and request an allowed but harmful action. Keep sensitive operations behind explicit authorization rules and meaningful human review.
Bearer tokens can also be stolen and reused within their permitted access. Audience checks limit where a token is accepted, but do not make a stolen token harmless at its intended server. Protect token storage and investigate unexpected access.
Broader MCP security includes server trust, tool behavior, software provenance, and data handling. Authentication establishes an access boundary. It does not establish that every action inside that boundary is safe.
How Identra thinks about it
Identra discovers MCP servers and the AI clients and coding agents that use them on macOS and Windows endpoints, giving teams an inventory to drive access reviews. In connected identity providers, OAuth grants are collected with the app, permissions and grantor, and analysts can revoke risky grants. Every AI agent run on the endpoint is recorded with the user, device, AI client and outcome.
Go deeper: Identra on the endpoint
Frequently asked questions
Is authentication mandatory for every MCP server?
Authorization is optional in the protocol. Enterprises should require authentication and authorization whenever a server exposes private data or privileged operations.
Does an OAuth client ID authenticate an AI agent?
A client ID identifies an application registration. By itself, it is not a secret or proof of a particular agent's identity, and it does not identify an individual agent run.
Can an MCP server use an API key?
Implementations can use API keys, including for downstream services. A static key alone does not implement MCP's HTTP OAuth authorization framework or provide user delegation, so check interoperability and accountability requirements.
Does PKCE prevent access token theft?
PKCE protects the authorization code exchange. It does not protect an access token that is later exposed through storage, logs, or a compromised process.
Can the same token be forwarded to a downstream API?
MCP prohibits token passthrough. The downstream API should receive a separate token issued for that API, with permissions appropriate to the requested operation.