MCP Authentication
OAuth 2.1 + PKCE is the MCP spec requirement for HTTP servers — not a suggestion. Learn the discovery flow, per-user delegated auth via interceptors, what the spec forbids (token passthrough, audience-skipping), and when you need auth at all.
Quick Reference
- →stdio transport: no auth needed — credentials come from the process environment, not the client config
- →HTTP transport: OAuth 2.1 + PKCE is the MCP spec standard — most remote servers require it
- →Discovery: client hits server → 401 with resource_metadata URL → fetches Protected Resource Metadata (RFC 9728) → finds auth server
- →PKCE is mandatory — if auth server metadata lacks code_challenge_methods_supported, the spec says refuse to proceed
- →Resource Indicators (RFC 8707): token must be audience-bound to the target MCP server URL — prevents cross-server token reuse
- →Delegated auth: per-user tokens injected via interceptors from runtime.context — never stored in agent state or checkpoints
- →Token passthrough is explicitly forbidden — MCP servers must validate tokens, not forward them to upstream APIs
- →Fleet OAuth: LangSmith Fleet handles OAuth 2.1 natively — users authenticate once, Fleet injects scoped tokens per MCP server
When Do You Need MCP Auth?
Auth requirements depend on transport, not protocol. Stdio transport explicitly does NOT use the OAuth spec — credentials come from the process environment, injected before the agent starts. HTTP-based transports are where OAuth 2.1 applies, but only when the server enforces it.
Internal tools and third-party APIs with no user data → API key in headers. Gmail, Slack, Salesforce, or anything where each user has their own account → OAuth 2.1 with delegated auth. See the decision tree below.
stdio → env creds · HTTP + no user data → API key · user data → delegated or proxy