MCP Authentication: OAuth, Tokens & Access Control

How MCP Authentication Works

MCP authentication operates at two layers. The first layer authenticates the user or system that owns the agent -- proving they have a valid account and have granted consent for the agent to act on their behalf. The second layer authenticates the agent session itself, ensuring that a specific agent instance has a valid, non-expired credential to make tool calls. In practice, this usually means the user completes an OAuth consent flow once, the resulting tokens are stored securely, and the agent presents a session token or bearer token with each MCP request. The MCP server (or an intermediary gateway) validates this token before executing any tool call. Without both layers, you either have unauthenticated agents accessing services (a security disaster) or no way to distinguish between different agents acting on behalf of the same user.

OAuth 2.0 for MCP Servers

OAuth 2.0 is the dominant authentication mechanism for MCP servers that connect to third-party services like Google, GitHub, Slack, and Microsoft 365. The MCP specification recommends OAuth 2.1 (which mandates PKCE and removes the implicit grant) for new implementations. The flow works as follows: the user initiates a connection through the MCP gateway, is redirected to the service provider's consent screen, grants specific scopes, and the resulting access and refresh tokens are stored by the gateway -- never by the agent itself. This separation is critical: agents should never hold raw OAuth tokens. Instead, they receive a scoped session identifier that the gateway resolves to the appropriate credential at call time. This prevents token theft if the agent or its runtime environment is compromised.

Token Management for MCP

Effective token management is the backbone of MCP authentication. Access tokens are short-lived (typically 1 hour) and must be refreshed automatically using refresh tokens before expiry. The refresh token itself should be encrypted at rest and stored in a secure backend -- never in browser storage, environment variables, or agent memory. Token rotation policies should invalidate refresh tokens after use (one-time rotation) to prevent replay attacks. For multi-server environments, each MCP server connection should have its own token pair, isolated from others. If one server's credentials are compromised, the blast radius is limited to that server's scopes. The gateway should also support instant token revocation: a single API call that immediately invalidates all tokens for a specific agent, user, or service connection.

MCP Authentication Best Practices

Never let agents store or manage OAuth tokens directly -- centralize credential storage in a gateway or secrets manager. Use the narrowest possible OAuth scopes for each connection. Implement token rotation and automatic refresh with encrypted storage. Enforce session timeouts: agent sessions should expire after a configurable period of inactivity, requiring re-authentication. Use mutual TLS or signed requests for server-to-server MCP connections in high-security environments. Log every authentication event (token issue, refresh, revocation, failure) with timestamps and agent identifiers for audit compliance. Finally, support instant revocation at the agent, user, and service level -- when an agent is decommissioned or a user leaves the organization, all associated credentials should be invalidated immediately.

Frequently Asked Questions

Related Terms