OAuth Authentication
Authenticate your FastMCP client via OAuth 2.1.
New in version: 2.6.0
OAuth authentication is only relevant for HTTP-based transports and requires user interaction via a web browser.
When your FastMCP client needs to access an MCP server protected by OAuth 2.1, and the process requires user interaction (like logging in and granting consent), you should use the Authorization Code Flow. FastMCP provides the fastmcp.client.auth.OAuth
helper to simplify this entire process.
This flow is common for user-facing applications where the application acts on behalf of the user.
Client Usage
Default Configuration
The simplest way to use OAuth is to pass the string "oauth"
to the auth
parameter of the Client
or transport instance. FastMCP will automatically configure the client to use OAuth with default settings:
OAuth
Helper
To fully configure the OAuth flow, use the OAuth
helper and pass it to the auth
parameter of the Client
or transport instance. OAuth
manages the complexities of the OAuth 2.1 Authorization Code Grant with PKCE (Proof Key for Code Exchange) for enhanced security, and implements the full httpx.Auth
interface.
OAuth
Parameters
mcp_url
(str
): The full URL of the target MCP server endpoint. Used to discover OAuth server metadatascopes
(str | list[str]
, optional): OAuth scopes to request. Can be space-separated string or list of stringsclient_name
(str
, optional): Client name for dynamic registration. Defaults to"FastMCP Client"
token_storage_cache_dir
(Path
, optional): Token cache directory. Defaults to~/.fastmcp/oauth-mcp-client-cache/
additional_client_metadata
(dict[str, Any]
, optional): Extra metadata for client registration
OAuth Flow
The OAuth flow is triggered when you use a FastMCP Client
configured to use OAuth.
Token Check
The client first checks the token_storage_cache_dir
for existing, valid tokens for the target server. If one is found, it will be used to authenticate the client.
OAuth Server Discovery
If no valid tokens exist, the client attempts to discover the OAuth server’s endpoints using a well-known URI (e.g., /.well-known/oauth-authorization-server
) based on the mcp_url
.
Dynamic Client Registration
If the OAuth server supports it and the client isn’t already registered (or credentials aren’t cached), the client performs dynamic client registration according to RFC 7591.
Local Callback Server
A temporary local HTTP server is started on an available port. This server’s address (e.g., http://127.0.0.1:<port>/callback
) acts as the redirect_uri
for the OAuth flow.
Browser Interaction
The user’s default web browser is automatically opened, directing them to the OAuth server’s authorization endpoint. The user logs in and grants (or denies) the requested scopes
.
Authorization Code & Token Exchange
Upon approval, the OAuth server redirects the user’s browser to the local callback server with an authorization_code
. The client captures this code and exchanges it with the OAuth server’s token endpoint for an access_token
(and often a refresh_token
) using PKCE for security.
Token Caching
The obtained tokens are saved to the token_storage_cache_dir
for future use, eliminating the need for repeated browser interactions.
Authenticated Requests
The access token is automatically included in the Authorization
header for requests to the MCP server.
Refresh Token
If the access token expires, the client will automatically use the refresh token to get a new access token.
Token Management
Token Storage
OAuth access tokens are automatically cached in ~/.fastmcp/oauth-mcp-client-cache/
and persist between application runs. Files are keyed by the OAuth server’s base URL.
Managing Cache
To clear the tokens for a specific server, instantiate a FileTokenStorage
instance and call the clear
method:
To clear all tokens for all servers, call the clear_all
method on the FileTokenStorage
class: