New in version: 2.12.0
OAuth Proxy enables FastMCP servers to authenticate with OAuth providers that don’t support Dynamic Client Registration (DCR). This includes virtually all traditional OAuth providers: GitHub, Google, Azure, AWS, Discord, Facebook, and most enterprise identity systems. For providers that do support DCR (like Descope and WorkOS AuthKit), use RemoteAuthProvider
instead.
MCP clients expect to register automatically and obtain credentials on the fly, but traditional providers require manual app registration through their developer consoles. OAuth Proxy bridges this gap by presenting a DCR-compliant interface to MCP clients while using your pre-registered credentials with the upstream provider. When a client attempts to register, the proxy returns your fixed credentials. When a client initiates authorization, the proxy handles the complexity of callback forwarding—storing the client’s dynamic callback URL, using its own fixed callback with the provider, then forwarding back to the client after token exchange.
This approach enables any MCP client (whether using random localhost ports or fixed URLs like Claude.ai) to authenticate with any traditional OAuth provider, all while maintaining full OAuth 2.1 and PKCE security.
For providers that support OIDC discovery (Auth0, Google with OIDC
configuration, Azure AD), consider using
OIDC Proxy
for automatic configuration. OIDC Proxy
extends OAuth Proxy to automatically discover endpoints from the provider’s
/.well-known/openid-configuration
URL, simplifying setup.Implementation
Provider Setup Requirements
Before using OAuth Proxy, you need to register your application with your OAuth provider:- Register your application in the provider’s developer console (GitHub Settings, Google Cloud Console, Azure Portal, etc.)
- Configure the redirect URI as your FastMCP server URL plus your chosen callback path:
- Default:
https://your-server.com/auth/callback
- Custom:
https://your-server.com/your/custom/path
(if you setredirect_path
) - Development:
http://localhost:8000/auth/callback
- Default:
- Obtain your credentials: Client ID and Client Secret
- Note the OAuth endpoints: Authorization URL and Token URL (usually found in the provider’s OAuth documentation)
The redirect URI you configure with your provider must exactly match your
FastMCP server’s URL plus the callback path. If you customize
redirect_path
in OAuth Proxy, update your provider’s redirect URI accordingly.Basic Setup
Here’s how to implement OAuth Proxy with any provider:Configuration Parameters
OAuthProxy Parameters
URL of your OAuth provider’s authorization endpoint (e.g.,
https://github.com/login/oauth/authorize
)URL of your OAuth provider’s token endpoint (e.g.,
https://github.com/login/oauth/access_token
)Client ID from your registered OAuth application
Client secret from your registered OAuth application
A
TokenVerifier
instance to validate the
provider’s tokensPublic URL of your FastMCP server (e.g.,
https://your-server.com
)Path for OAuth callbacks. Must match the redirect URI configured in your OAuth
application
Optional URL of provider’s token revocation endpoint
Issuer URL for OAuth metadata (defaults to base_url)
Optional URL to your service documentation
Whether to forward PKCE (Proof Key for Code Exchange) to the upstream OAuth
provider. When enabled and the client uses PKCE, the proxy generates its own
PKCE parameters to send upstream while separately validating the client’s
PKCE. This ensures end-to-end PKCE security at both layers (client-to-proxy
and proxy-to-upstream). -
True
(default): Forward PKCE for providers that
support it (Google, Azure, AWS, GitHub, etc.) - False
: Disable only if upstream
provider doesn’t support PKCEToken endpoint authentication method for the upstream OAuth server. Controls
how the proxy authenticates when exchanging authorization codes and refresh
tokens with the upstream provider. -
"client_secret_basic"
: Send credentials
in Authorization header (most common) - "client_secret_post"
: Send
credentials in request body (required by some providers) - "none"
: No
authentication (for public clients) - None
(default): Uses authlib’s default
(typically "client_secret_basic"
) Set this if your provider requires a
specific authentication method and the default doesn’t work.List of allowed redirect URI patterns for MCP clients. Patterns support
wildcards (e.g.,
"http://localhost:*"
, "https://*.example.com/*"
). -
None
(default): All redirect URIs allowed (for MCP/DCR compatibility) -
Empty list []
: No redirect URIs allowed - Custom list: Only matching
patterns allowed These patterns apply to MCP client loopback redirects, NOT
the upstream OAuth app redirect URI.List of all possible valid scopes for the OAuth provider. These are advertised
to clients through the
/.well-known
endpoints. Defaults to required_scopes
from your TokenVerifier if not specified.Additional parameters to forward to the upstream authorization endpoint. Useful for provider-specific parameters that aren’t part of the standard OAuth2 flow.For example, Auth0 requires an These parameters are added to every authorization request sent to the upstream provider.
audience
parameter to issue JWT tokens:Additional parameters to forward to the upstream token endpoint during code exchange and token refresh. Useful for provider-specific requirements during token operations.For example, some providers require additional context during token exchange:These parameters are included in all token requests to the upstream provider.
Storage backend for persisting OAuth client registrations. By default, clients are automatically persisted to disk in
~/.config/fastmcp/oauth-proxy-clients/
, allowing them to survive server restarts as long as the filesystem remains accessible. This means MCP clients only need to register once and can reconnect seamlessly after your server restarts.Provider-Specific Parameters
Some OAuth providers require additional parameters beyond the standard OAuth2 flow. Useextra_authorize_params
and extra_token_params
to handle these requirements:
Auth0 Example
Auth0 requires anaudience
parameter to issue JWT tokens instead of opaque tokens:
RFC 8707 Resource Indicators
MCP clients can specify target resources using the standardresource
parameter (RFC 8707). This is automatically forwarded when present:
Using Built-in Providers
FastMCP includes pre-configured providers for common services:GitHubProvider
, GoogleProvider
, and others. These handle token verification automatically.
Scope Configuration
OAuth scopes are configured through yourTokenVerifier
. Set required_scopes
to automatically request the permissions your application needs:
How It Works
The flow diagram above illustrates the complete OAuth Proxy pattern. Let’s understand each phase:Registration Phase
When an MCP client calls/register
with its dynamic callback URL, the proxy responds with your pre-configured upstream credentials. The client stores these credentials believing it has registered a new app. Meanwhile, the proxy records the client’s callback URL for later use.
Authorization Phase
The client initiates OAuth by redirecting to the proxy’s/authorize
endpoint. The proxy:
- Stores the client’s transaction with its PKCE challenge
- Generates its own PKCE parameters for upstream security
- Redirects to the upstream provider using the fixed callback URL
Callback Phase
After user authorization, the provider redirects back to the proxy’s fixed callback URL. The proxy:- Exchanges the authorization code for tokens with the provider
- Stores these tokens temporarily
- Generates a new authorization code for the client
- Redirects to the client’s original dynamic callback URL
Token Exchange Phase
Finally, the client exchanges its authorization code with the proxy to receive the provider’s tokens. The proxy validates the client’s PKCE verifier before returning the stored tokens. This entire flow is transparent to the MCP client—it experiences a standard OAuth flow with dynamic registration, unaware that a proxy is managing the complexity behind the scenes.PKCE Forwarding
OAuth Proxy automatically handles PKCE (Proof Key for Code Exchange) when working with providers that support or require it. The proxy generates its own PKCE parameters to send upstream while separately validating the client’s PKCE, ensuring end-to-end security at both layers. This is enabled by default via theforward_pkce
parameter and works seamlessly with providers like Google, Azure AD, and GitHub. Only disable it for legacy providers that don’t support PKCE:
Redirect URI Validation
While OAuth Proxy accepts all redirect URIs by default (for DCR compatibility), you can restrict which clients can connect by specifying allowed patterns:Token Verification
OAuth Proxy requires a compatibleTokenVerifier
to validate tokens from your provider. Different providers use different token formats:
- JWT tokens (Google, Azure): Use
JWTVerifier
with the provider’s JWKS endpoint - Opaque tokens (GitHub, Discord): Use provider-specific verifiers or implement custom validation
Environment Configuration
New in version: 2.12.1
For production deployments, configure OAuth Proxy through environment variables instead of hardcoding credentials: