Skip to main content
Authentication verifies the identity associated with a request. In an MCP system, identity may need to be verified at more than one boundary.
Authentication answers “Who is making this request?” Authorization answers “What may that identity do?”

​
Authentication and authorization are different

MCP’s standard for protected HTTP servers is formally an authorization specification built on OAuth conventions. User authentication usually happens at the authorization server and may use passwords, passkeys, enterprise identity, or OpenID Connect.

​
Three credential boundaries

​
User to authorization server

The authorization server authenticates the user and obtains consent. The exact login method is outside the MCP specification.

​
MCP client to MCP server

For a protected remote server, the client sends an access token:
The MCP server validates the token before serving protected requests.

​
MCP server to upstream API

An MCP server may need a separate credential for the external API it wraps. That credential may be:
  • A user-specific OAuth token
  • A service-account token
  • An API key
  • A credential obtained through token exchange
The upstream credential must be intended for the upstream system. Do not forward an MCP access token to another API unchanged.

​
Remote MCP server authentication

For HTTP-based transports, the current MCP specification defines an OAuth-based access flow. The main roles are: The authorization server can be operated by the same organization as the MCP server or by a separate identity provider.

​
What the MCP server validates

For each protected request, validate:
  • The token signature or introspection result
  • The trusted issuer
  • The intended audience or resource
  • Expiration and not-before times
  • Required scopes or claims
  • Revocation status when supported
  • The token type and allowed algorithm
Reject a token issued for another service, even if its signature is valid.
Decoding a JWT is not validation. Verify its signature, issuer, audience, time claims, and authorization data with trusted configuration.

​
Local MCP server credentials

The MCP OAuth authorization flow is intended for HTTP-based transports. A local stdio server normally obtains credentials through its environment or a secure local credential mechanism. For local servers:
  • Pass only required environment variables.
  • Use the client’s secure credential store when available.
  • Keep secrets out of shared configuration files.
  • Restrict configuration file permissions.
  • Do not print credentials to stdout or stderr.
  • Treat the local server package as code running with the user’s privileges.

​
Authentication for API-backed MCP servers

An API-backed server needs a deliberate upstream credential model.

​
User credential forwarding

The client supplies a credential issued for the upstream API. The MCP layer forwards it to that API. This preserves upstream identity and permissions, but the credential must remain confidential and must not appear in model-visible content or logs.

​
Service credential

The MCP server uses its own service identity. This simplifies upstream access but requires the MCP server to enforce user-level authorization. Every action may otherwise appear to originate from one highly privileged account.

​
OAuth delegation or token exchange

The system obtains an upstream token with a specific audience and limited scope. This is appropriate when the MCP server must act on behalf of a user without reusing the MCP token.

​
How 0mcp handles upstream credentials

0mcp uses a pass-through model for credentials explicitly provided for your upstream API. It can forward bearer tokens or API keys according to your configured API source:
  • The published security scheme for OpenAPI 3.x or Swagger 2.0
  • The authentication configuration for a directly connected REST API
  • The authentication configuration for a GraphQL API
All three source types use the same credential-forwarding model. Your API remains responsible for validating the credential and authorizing the request. This upstream credential is conceptually separate from any access token used to protect the MCP endpoint itself. Read the 0mcp authentication model for supported forwarding patterns.

​
Common authentication failures

See Authentication errors for 0mcp troubleshooting.

​
Authentication best practices

  • Use HTTPS for remote MCP traffic.
  • Prefer short-lived, audience-restricted tokens.
  • Use PKCE in authorization code flows.
  • Never put credentials in URLs.
  • Store refresh tokens and long-lived credentials securely.
  • Redact credentials from logs and telemetry.
  • Rotate credentials after suspected compromise.
  • Rate-limit authentication failures.
  • Keep MCP and upstream API credentials separate.
  • Use multi-factor authentication at the identity provider for sensitive access.

​
What authentication does not solve

Authentication does not:
  • Decide which tools a user may call
  • Limit which records a user may access
  • Prevent prompt injection
  • Make tool arguments safe
  • Replace user confirmation
  • Protect a server that ignores token scopes
Apply MCP authorization, input validation, and least privilege after identity is established.

​
Key takeaway

MCP authentication establishes the identities and credentials at each boundary, while authorization and server policy decide what those identities can do.