🎉 学 LangChain 免费领 openAI GPT key 限额1000名 →
新版文档(v1.x)
langchain
mcp
Authentication

Authentication

import McpAuthBearerPy from '/snippets/code-samples/mcp-auth-bearer-py.mdx'; import McpAuthOauthPy from '/snippets/code-samples/mcp-auth-oauth-py.mdx'; import McpAuthPerServerPy from '/snippets/code-samples/mcp-auth-per-server-py.mdx'; import McpAuthPerUserPy from '/snippets/code-samples/mcp-auth-per-user-py.mdx';

Most remote MCP servers require authentication. @[MCPAdapter] delegates auth to FastMCP, so any credential a fastmcp.Client accepts works: a static bearer token, a full OAuth 2.1 flow, or any httpx.Auth (opens in a new tab). Pass the credential on a prebuilt client and hand that client to the adapter. When one agent talks to several servers, use per-server authentication; in a deployment, use per-user authentication so each run reaches the server as the caller.

The langchain.mcp namespace requires langchain[mcp]>=1.4.0 and is in beta. The API may change.

Bearer token

The simplest case: the server verifies a token you provisioned and adds it in the Authorization: Bearer <token> header. There is no discovery, browser, or refresh. Pass the token as the client's auth:

The auth argument accepts a bearer-token string, the literal "oauth", or any httpx.Auth. In an MCPConfig fleet, each server takes the same key.

OAuth authentication

For a server that issues its own credentials, pass the literal string "oauth". FastMCP runs the full OAuth 2.1 flow: discovery, dynamic client registration (opens in a new tab), the browser redirect, and the token exchange. Dynamic client registration means the client registers itself at runtime instead of you pre-provisioning a client ID:

By default tokens are held in memory, so each run repeats the browser step. Pass a prebuilt OAuth provider with a token store to persist them across runs:

from fastmcp.client import Client
from fastmcp.client.auth import OAuth
 
oauth = OAuth(mcp_url="https://example.com/mcp", token_storage=...)
client = Client("https://example.com/mcp", auth=oauth)

FastMCP ships providers for common identity providers (Auth0, WorkOS, Okta, and more); the flow the client runs is identical across them. See OAuth authentication (opens in a new tab) in the FastMCP documentation.

Per-server authentication

When one agent talks to several servers, each server may need its own credential. Give each its own connection with a ClientGroup (opens in a new tab), and set auth per client, so every server authenticates independently:

Per-user authentication

In a deployment, each run should reach the MCP server as the user who initiated it, not with one shared credential. The pattern has two halves:

  1. Authenticate the caller at the LangGraph server. A custom auth handler resolves the incoming request to a user identity, which each run reads off its runtime.
  2. Mint or exchange a credential for that user. Inside the graph factory (opens in a new tab), read the user's identity and build the MCP client with a per-user token, so the connection carries that user's authorization.

In production, token_for stands in for whatever the deployment already has: an OAuth gateway that exchanges the session for a per-user token, or a fastmcp.client.auth provider that runs the authorization-code flow per identity. Isolate any cached responses (opens in a new tab) per user, keyed off the verified identity, so one user never sees another's cached tool list.

See also

OpenUIConnections