URL: https://gofastmcp.com/servers/auth/authentication
Title: Authentication - FastMCP

Documentation Index
Fetch the complete documentation index at:
/llms.txt
Use this file to discover all available pages before exploring further.
Skip to main content
Meet
Prefect Horizon
, the enterprise MCP gateway built by the team behind FastMCP
FastMCP
home page
v3
Prefect Horizon
PrefectHQ/fastmcp
25,596
PrefectHQ/fastmcp
25,596
Search...
Navigation
Authentication
Authentication
Search the docs...
Ctrl
K
Documentation
Get Started
Welcome!
Installation
Quickstart
Servers
Overview
Core Components
Working with Tools
MCP Providers
Interactivity
Extensibility
Auth
Authentication
Overview
Token Verification
Remote OAuth
OAuth Proxy
OIDC Proxy
Full OAuth Server
Multiple Auth Sources
Authorization
NEW
Deployment
Apps
Overview
Quickstart
NEW
FastMCPApp
NEW
Interactive Tools
NEW
Generative UI
NEW
Custom HTML
Reference
Clients
Overview
Client-Only Package
Transports
fastmcp-remote
Operations
UPDATED
Authentication
UPDATED
Integrations
Auth
Web Frameworks
AI Assistants
AI SDKs
MCP.json
More
Settings
CLI
Upgrading
Development
What's New
FAQ
On this page
MCP Authentication Challenges
Authentication Responsibility
Token Validation
External Identity Providers
Full OAuth Implementation
FastMCP Authentication Providers
TokenVerifier
RemoteAuthProvider
OAuthProxy
OAuthProvider
MultiAuth
Configuration
Choosing Your Implementation
Authentication
Authentication
Copy page
Secure your FastMCP server with flexible authentication patterns, from simple API keys to full OAuth 2.1 integration with external identity providers.
Copy page
New in version
2.11.0
Authentication in MCP presents unique challenges that differ from traditional web applications. MCP clients need to discover authentication requirements automatically, negotiate OAuth flows without user intervention, and work seamlessly across different identity providers. FastMCP addresses these challenges by providing authentication patterns that integrate with the MCP protocol while remaining simple to implement and deploy.
Authentication applies only to FastMCP’s HTTP-based transports (
http
and
sse
). The STDIO transport inherits security from its local execution environment.
Authentication is rapidly evolving in MCP.
The specification and best practices are changing quickly. FastMCP aims to provide stable, secure patterns that adapt to these changes while keeping your code simple and maintainable.
​
MCP Authentication Challenges
Traditional web authentication assumes a human user with a browser who can interact with login forms and consent screens. MCP clients are often automated systems that need to authenticate without human intervention. This creates several unique requirements:
Automatic Discovery
: MCP clients must discover authentication requirements by examining server metadata rather than encountering login redirects.
Programmatic OAuth
: OAuth flows must work without human interaction, relying on pre-configured credentials or Dynamic Client Registration.
Token Management
: Clients need to obtain, refresh, and manage tokens automatically across multiple MCP servers.
Protocol Integration
: Authentication must integrate cleanly with MCP’s transport mechanisms and error handling.
These challenges mean that not all authentication approaches work well with MCP. The patterns that do work fall into three categories based on the level of authentication responsibility your server assumes.
​
Authentication Responsibility
Authentication responsibility exists on a spectrum. Your MCP server can validate tokens created elsewhere, coordinate with external identity providers, or handle the complete authentication lifecycle internally. Each approach involves different trade-offs between simplicity, security, and control.
​
Token Validation
Your server validates tokens but delegates their creation to external systems. This approach treats your MCP server as a pure resource server that trusts tokens signed by known issuers.
Token validation works well when you already have authentication infrastructure that can issue structured tokens like JWTs. Your existing API gateway, microservices platform, or enterprise SSO system becomes the source of truth for user identity, while your MCP server focuses on its core functionality.
The key insight is that token validation separates authentication (proving who you are) from authorization (determining what you can do). Your MCP server receives proof of identity in the form of a signed token and makes access decisions based on the claims within that token.
This pattern excels in microservices architectures where multiple services need to validate the same tokens, or when integrating MCP servers into existing systems that already handle user authentication.
​
External Identity Providers
Your server coordinates with established identity providers to create seamless authentication experiences for MCP clients. This approach leverages OAuth 2.0 and OpenID Connect protocols to delegate user authentication while maintaining control over authorization decisions.
External identity providers handle the complex aspects of authentication: user credential verification, multi-factor authentication, account recovery, and security monitoring. Your MCP server receives tokens from these trusted providers and validates them using the provider’s public keys.
The MCP protocol’s support for Dynamic Client Registration makes this pattern particularly powerful. MCP clients can automatically discover your authentication requirements and register themselves with your identity provider without manual configuration.
This approach works best for production applications that need enterprise-grade authentication features without the complexity of building them from scratch. It scales well across multiple applications and provides consistent user experiences.
​
Full OAuth Implementation
Your server implements a complete OAuth 2.0 authorization server, handling everything from user credential verification to token lifecycle management. This approach provides maximum control at the cost of significant complexity.
Full OAuth implementation means building user interfaces for login and consent, implementing secure credential storage, managing token lifecycles, and maintaining ongoing security updates. The complexity extends beyond initial implementation to include threat monitoring, compliance requirements, and keeping pace with evolving security best practices.
This pattern makes sense only when you need complete control over the authentication process, operate in air-gapped environments, or have specialized requirements that external providers cannot meet.
​
FastMCP Authentication Providers
FastMCP translates these authentication responsibility levels into a variety of concrete classes that handle the complexities of MCP protocol integration. You can build on these classes to handle the complexities of MCP protocol integration.
​
TokenVerifier
TokenVerifier
provides pure token validation without OAuth metadata endpoints. This class focuses on the essential task of determining whether a token is valid and extracting authorization information from its claims.
The implementation handles JWT signature verification, expiration checking, and claim extraction. It validates tokens against known issuers and audiences, ensuring that tokens intended for your server are not accepted by other systems.
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
.
providers
.
jwt
import
JWTVerifier
auth
=
JWTVerifier
(
jwks_uri
=
"
https://your-auth-system.com/.well-known/jwks.json
"
,
issuer
=
"
https://your-auth-system.com
"
,
audience
=
"
your-mcp-server
"
)
mcp
=
FastMCP
(
name
=
"
Protected Server
"
,
auth
=
auth
)
This example configures token validation against a JWT issuer. The
JWTVerifier
will fetch public keys from the JWKS endpoint and validate incoming tokens against those keys. Only tokens with the correct issuer and audience claims will be accepted.
TokenVerifier
works well when you control both the token issuer and your MCP server, or when integrating with existing JWT-based infrastructure.
→
Complete guide
:
Token Verification
​
RemoteAuthProvider
RemoteAuthProvider
enables authentication with identity providers that
support Dynamic Client Registration (DCR)
, such as Descope and WorkOS AuthKit. With DCR, MCP clients can automatically register themselves with the identity provider and obtain credentials without any manual configuration.
This class combines token validation with OAuth discovery metadata. It extends
TokenVerifier
functionality by adding OAuth 2.0 protected resource endpoints that advertise your authentication requirements. MCP clients examine these endpoints to understand which identity providers you trust and how to obtain valid tokens.
The key requirement is that your identity provider must support DCR - the ability for clients to dynamically register and obtain credentials. This is what enables the seamless, automated authentication flow that MCP requires.
For example, the built-in
AuthKitProvider
uses WorkOS AuthKit, which fully supports DCR:
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
.
providers
.
workos
import
AuthKitProvider
auth
=
AuthKitProvider
(
authkit_domain
=
"
https://your-project.authkit.app
"
,
base_url
=
"
https://your-fastmcp-server.com
"
)
mcp
=
FastMCP
(
name
=
"
Enterprise Server
"
,
auth
=
auth
)
This example uses WorkOS AuthKit as the external identity provider. The
AuthKitProvider
automatically configures token validation against WorkOS and provides the OAuth metadata that MCP clients need for automatic authentication.
RemoteAuthProvider
is ideal for production applications when your identity provider supports Dynamic Client Registration (DCR). This enables fully automated authentication without manual client configuration.
→
Complete guide
:
Remote OAuth
​
OAuthProxy
New in version
2.12.0
OAuthProxy
enables authentication with OAuth providers that
don’t support Dynamic Client Registration (DCR)
, such as GitHub, Google, Azure, AWS, and most traditional enterprise identity systems.
When identity providers require manual app registration and fixed credentials,
OAuthProxy
bridges the gap. It presents a DCR-compliant interface to MCP clients (accepting any registration request) while using your pre-registered credentials with the upstream provider. The proxy handles the complexity of callback forwarding, enabling dynamic client callbacks to work with providers that require fixed redirect URIs.
This class solves the fundamental incompatibility between MCP’s expectation of dynamic registration and traditional OAuth providers’ requirement for manual app registration.
For example, the built-in
GitHubProvider
extends
OAuthProxy
to work with GitHub’s OAuth system:
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
.
providers
.
github
import
GitHubProvider
auth
=
GitHubProvider
(
client_id
=
"
Ov23li...
"
,
# Your GitHub OAuth App ID
client_secret
=
"
abc123...
"
,
# Your GitHub OAuth App Secret
base_url
=
"
https://your-server.com
"
)
mcp
=
FastMCP
(
name
=
"
GitHub-Protected Server
"
,
auth
=
auth
)
This example uses the GitHub provider, which extends
OAuthProxy
with GitHub-specific token validation. The proxy handles the complete OAuth flow while making GitHub’s non-DCR authentication work seamlessly with MCP clients.
OAuthProxy
is essential when integrating with OAuth providers that don’t support DCR. This includes most established providers like GitHub, Google, and Azure, which require manual app registration through their developer consoles.
→
Complete guide
:
OAuth Proxy
​
OAuthProvider
OAuthProvider
implements a complete OAuth 2.0 authorization server within your MCP server. This class handles the full authentication lifecycle from user credential verification to token management.
The implementation provides all required OAuth endpoints including authorization, token, and discovery endpoints. It manages client registration, user consent, and token lifecycle while integrating with your user storage and authentication logic.
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
import
OAuthProvider
auth
=
MyOAuthProvider
(
user_store
=
your_user_database
,
client_store
=
your_client_registry
,
# Additional configuration...
)
mcp
=
FastMCP
(
name
=
"
Auth Server
"
,
auth
=
auth
)
This example shows the basic structure of a custom OAuth provider. The actual implementation requires significant additional configuration for user management, client registration, and security policies.
OAuthProvider
should be used only when you have specific requirements that external providers cannot meet and the expertise to implement OAuth securely.
→
Complete guide
:
Full OAuth Server
​
MultiAuth
New in version
3.1.0
MultiAuth
composes multiple authentication sources into a single
auth
provider. When a server needs to accept tokens from different issuers — for example, an OAuth proxy for interactive clients alongside JWT verification for machine-to-machine tokens —
MultiAuth
tries each source in order and accepts the first successful verification.
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
import
MultiAuth
,
OAuthProxy
from
fastmcp
.
server
.
auth
.
providers
.
jwt
import
JWTVerifier
auth
=
MultiAuth
(
server
=
OAuthProxy
(
issuer_url
=
"
https://login.example.com/...
"
,
client_id
=
"
my-app
"
,
client_secret
=
"
secret
"
,
base_url
=
"
https://my-server.com
"
,
),
verifiers
=[
JWTVerifier
(
jwks_uri
=
"
https://internal-issuer.example.com/.well-known/jwks.json
"
,
issuer
=
"
https://internal-issuer.example.com
"
,
audience
=
"
my-mcp-server
"
,
),
],
)
mcp
=
FastMCP
(
"
My Server
"
,
auth
=
auth
)
The server (if provided) owns all OAuth routes and metadata. Verifiers contribute only token verification logic. This keeps the MCP discovery surface clean while supporting multiple token sources.
→
Complete guide
:
Multiple Auth Sources
​
Configuration
Authentication providers are configured programmatically by instantiating them directly in your code with their required parameters. This makes dependencies explicit and allows your IDE to provide helpful autocompletion and type checking.
For production deployments, load sensitive values like client secrets from environment variables:
import
os
from
fastmcp
import
FastMCP
from
fastmcp
.
server
.
auth
.
providers
.
github
import
GitHubProvider
# Load secrets from environment variables
auth
=
GitHubProvider
(
client_id
=
os
.
environ
.
get
(
"
GITHUB_CLIENT_ID
"
),
client_secret
=
os
.
environ
.
get
(
"
GITHUB_CLIENT_SECRET
"
),
base_url
=
os
.
environ
.
get
(
"
BASE_URL
"
,
"
http://localhost:8000
"
)
)
mcp
=
FastMCP
(
name
=
"
My Server
"
,
auth
=
auth
)
This approach keeps secrets out of your codebase while maintaining explicit configuration. You can use any environment variable names you prefer - there are no special prefixes required.
​
Choosing Your Implementation
The authentication approach you choose depends on your existing infrastructure, security requirements, and operational constraints.
For OAuth providers without DCR support (GitHub, Google, Azure, AWS, most enterprise systems), use OAuth Proxy.
These providers require manual app registration through their developer consoles. OAuth Proxy bridges the gap by presenting a DCR-compliant interface to MCP clients while using your fixed credentials with the provider. The proxy’s callback forwarding pattern enables dynamic client ports to work with providers that require fixed redirect URIs.
For identity providers with DCR support (Descope, WorkOS AuthKit, modern auth platforms), use RemoteAuthProvider.
These providers allow clients to dynamically register and obtain credentials without manual configuration. This enables the fully automated authentication flow that MCP is designed for, providing the best user experience and simplest implementation.
Token validation works well when you already have authentication infrastructure that issues structured tokens.
If your organization already uses JWT-based systems, API gateways, or enterprise SSO that can generate tokens, this approach integrates seamlessly while keeping your MCP server focused on its core functionality. The simplicity comes from leveraging existing investment in authentication infrastructure.
When you need tokens from multiple sources, use MultiAuth.
This is common in hybrid architectures where interactive clients authenticate through an OAuth proxy while backend services send JWT tokens directly.
MultiAuth
composes an optional auth server with additional token verifiers, trying each source in order until one succeeds.
Full OAuth implementation should be avoided unless you have compelling reasons that external providers cannot address.
Air-gapped environments, specialized compliance requirements, or unique organizational constraints might justify this approach, but it requires significant security expertise and ongoing maintenance commitment. The complexity extends far beyond initial implementation to include threat monitoring, security updates, and keeping pace with evolving attack vectors.
FastMCP’s architecture supports migration between these approaches as your requirements evolve. You can integrate with existing token systems initially and migrate to external identity providers as your application scales, or implement custom solutions when your requirements outgrow standard patterns.
Versioning
Previous
Token Verification
Next
Ctrl
+I
discord
github
website
x
Powered by
This documentation is built and hosted on Mintlify, a developer documentation platform
Assistant
Responses are generated using AI and may contain mistakes.
\n\n
\n
\n \n
\n
