Skip to main content
This guide shows you how to secure your FastMCP server using Hugging Face OAuth. The HuggingFaceProvider uses FastMCP’s OAuth Proxy pattern with Hugging Face’s OAuth and OpenID Connect endpoints. It works with manually created confidential apps, public PKCE apps, and Client ID Metadata Documents (CIMD). When deploying your MCP server to Hugging Face Spaces, Spaces can create and manage the OAuth app for you.

Configuration

Prerequisites

Before you begin, you will need:
  1. A Hugging Face account with access to create OAuth apps
  2. Your FastMCP server’s URL (can be localhost for development, e.g., http://localhost:8000)

Step 1: Create a Hugging Face OAuth app

Create an OAuth app from your Hugging Face application settings. For details, see Hugging Face’s OAuth documentation.
1

Create the OAuth app

Go to your Hugging Face application settings and create a new OAuth application.Choose a name users will recognize, then configure the redirect URL for your FastMCP server:
  • Development: http://localhost:8000/auth/callback
  • Production: https://your-domain.com/auth/callback
The redirect URL must match exactly. The default path is /auth/callback, but you can customize it using the redirect_path parameter. For production, use HTTPS.
2

Save your credentials

After creating the app, save:
  • Client ID: The public identifier for your Hugging Face OAuth app
  • Client Secret: The app secret, if you created a confidential app
Store the client secret securely. Never commit it to version control. Use environment variables or a secrets manager in production.

Step 2: Configure FastMCP

server.py

Public OAuth apps, DCR, and CIMD

Hugging Face supports public OAuth apps (no client secret). For public apps, omit client_secret and provide a jwt_signing_key so FastMCP can sign its own proxy tokens:
MCP clients can use Dynamic Client Registration with your FastMCP server. The HuggingFaceProvider inherits FastMCP’s OAuth Proxy behavior, which handles client registration locally and forwards authorization to Hugging Face using your configured Hugging Face OAuth app. In other words, MCP clients register with FastMCP, while FastMCP uses your Hugging Face client_id and optional client_secret for the upstream OAuth flow. You can also use a Client ID Metadata Document URL as the client_id when your client metadata is hosted at a stable HTTPS URL:

Testing

Running the Server

Start your server with HTTP transport:
Your server is now running and protected by Hugging Face OAuth authentication.

Testing with a Client

Create a test client that authenticates with your Hugging Face-protected server:
test_client.py
When you run the client for the first time:
  1. Your browser will open to Hugging Face’s authorization page
  2. Sign in with your Hugging Face account and grant the requested permissions
  3. After authorization, you’ll be redirected back
  4. The client receives the token and can make authenticated requests
The client caches tokens locally, so you won’t need to re-authenticate for subsequent runs unless the token expires or you explicitly clear the cache.

Hugging Face Spaces

When deploying to Hugging Face Spaces, Spaces can create and manage the OAuth app for you. Add OAuth metadata to your Space README:
Spaces provide OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, OAUTH_SCOPES, OPENID_PROVIDER_URL, and SPACE_HOST environment variables:
Set JWT_SIGNING_KEY as a Space secret.

Hugging Face scopes

The default scopes are openid and profile. Add more scopes when your tools need Hub capabilities:
For organization resources, use Hugging Face’s normal OAuth organization grant flow. If you need a specific organization, pass Hugging Face’s orgIds authorization parameter. The value is the organization ID from the organizations.sub field in the Hugging Face userinfo response:

Production Configuration

For production deployments with persistent token management across server restarts, configure jwt_signing_key and client_storage:
server.py
Parameters (jwt_signing_key and client_storage) work together to ensure tokens and client registrations survive server restarts. Wrap your storage in FernetEncryptionWrapper to encrypt sensitive OAuth tokens at rest - without it, tokens are stored in plaintext. Store secrets in environment variables and use a persistent storage backend like Redis for distributed deployments.For complete details on these parameters, see the OAuth Proxy documentation.