RemoteAuthProvider instead.
The OIDC proxy is built upon OAuthProxy so it has all the same functionality under the covers.
Implementation
Provider Setup Requirements
Before using the OIDC proxy, you need to register your application with your OAuth provider:- Register your application in the provider’s developer console (Auth0 Applications, 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
Basic Setup
Here’s how to implement the OIDC proxy with any provider:Configuration Parameters
OIDCProxy Parameters
str
required
URL of your OAuth provider’s OIDC configuration
str
required
Client ID from your registered OAuth application
str | None
Client secret from your registered OAuth application. Optional for PKCE public
clients. When omitted,
jwt_signing_key must be provided.AnyHttpUrl | str
required
Public URL of your FastMCP server (e.g.,
https://your-server.com)AnyHttpUrl | str | None
Optional public base URL for the protected resource metadata and token audience.Use this when your OAuth callbacks and operational endpoints need to live under one public URL, but the protected MCP resource should be advertised under another. FastMCP will still append the MCP mount path (for example,
/mcp) to this base URL.bool | None
Strict flag for configuration validation. When True, requires all OIDC
mandatory fields.
str | None
Audience parameter for OIDC providers that require it (e.g., Auth0). This is
typically your API identifier.
int | None
default:"10"
HTTP request timeout in seconds for fetching OIDC configuration
TokenVerifier | None
Custom token verifier for validating tokens. When provided, FastMCP uses your custom verifier instead of creating a default
JWTVerifier.Cannot be used with algorithm or required_scopes parameters - configure these on your verifier instead. The verifier’s required_scopes are automatically loaded and advertised.str | None
JWT algorithm to use for token verification (e.g., “RS256”). If not specified,
uses the provider’s default. Only used when
token_verifier is not provided.list[str] | None
List of OAuth scopes for token validation. These are automatically
included in authorization requests. Only used when
token_verifier is not provided.str
default:"/auth/callback"
Path for OAuth callbacks. Must match the redirect URI configured in your OAuth
application
list[str] | None
List of allowed redirect URI patterns for MCP clients. Patterns support wildcards (e.g.,
"http://localhost:*", "https://*.example.com/*").None(default): DCR clients use registered redirect URIs, with loopback ports allowed to vary for MCP compatibility. Unsafe browser schemes such asjavascript:,data:,file:, andvbscript:are rejected.- Empty list
[]: No redirect URIs allowed - Custom list: Only matching patterns allowed
redirect_path.list[str] | None
The complete set of scopes clients are allowed to request — the full set of
available scopes (a superset of
required_scopes). These are advertised to
clients through the /.well-known endpoints (as scopes_supported) and
enforced at Dynamic Client Registration: a client registering with a scope
outside this set is rejected. Defaults to required_scopes from your token
verifier if not specified.str | None
Token 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")
str | bytes | None
Secret used to sign FastMCP JWT tokens issued to clients.
bytes are used as-is, with no stretching, so supply at least 32 bytes of high-entropy key material. With the default file-backed client storage, the bytes must also decode as UTF-8; use secrets.token_urlsafe(32).encode() instead of raw secrets.token_bytes(), or configure client_storage explicitly. A string is stretched into a 32-byte key with PBKDF2 (1,000,000 iterations), since a supplied string may be low-entropy.Default behavior (None):
The key is deterministically derived from client_secret using HKDF, on every platform. Because the derivation is deterministic, the same key is produced across restarts as long as client_secret doesn’t change, so tokens remain valid without any extra configuration. This convenience makes it only suitable for development and local testing.For production:
Provide an explicit jwt_signing_key (e.g., from an environment variable) rather than relying on the auto-derived key.AsyncKeyValue | None
Storage backend for persisting OAuth client registrations and upstream tokens.Default behavior:
Encrypted disk store in your platform’s data directory (derived from Production with encrypted Redis storage:
platformdirs), on every platform including Linux. The encryption key is itself derived from jwt_signing_key.By default, clients are automatically persisted to encrypted disk storage, 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.For production deployments with multiple servers or cloud deployments, use a network-accessible storage backend rather than local disk storage. Wrap your storage in FernetEncryptionWrapper to encrypt sensitive OAuth tokens at rest. See Storage Backends for available options.Testing with in-memory storage (unencrypted):bool | Literal["remember", "external"]
default:"True"
Consent screen behavior for authorization requests. Accepts
True (default; always prompt — strongest protection), "remember" (silent consent on return visits via signed cookie, gated by Sec-Fetch-Site to block AS-in-the-middle attacks), "external" (consent handled by upstream IdP or custom page), or False (disable entirely; local/testing only). See the OAuthProxy documentation for full details on each mode and the security trade-offs.str | None
default:"None"
Content Security Policy for the consent page.
None(default): Uses the built-in CSP policy with appropriate directives for form submission- Empty string
"": Disables CSP entirely (no meta tag rendered) - Custom string: Uses the provided value as the CSP policy
Using Built-in Providers
FastMCP includes pre-configured OIDC providers for common services:Auth0Provider at present.
Scope Configuration
OAuth scopes are configured withrequired_scopes to automatically request the permissions your application needs.
Dynamic clients created by the proxy will automatically include these scopes in their authorization requests.
CIMD Support
The OIDC proxy inherits full CIMD (Client ID Metadata Document) support fromOAuthProxy. Clients can use HTTPS URLs as their client_id instead of registering dynamically, and the proxy will fetch and validate their metadata document.
See the OAuth Proxy CIMD documentation for complete details on how CIMD works, including private key JWT authentication and security considerations.
The CIMD-related parameters available on OIDCProxy are:
CIMD Parameters
bool
default:"True"
Whether to accept CIMD URLs as client identifiers.

