2.13.0
This guide shows you how to secure your FastMCP server using Azure OAuth (Microsoft Entra ID). Since Azure doesnβt support Dynamic Client Registration, this integration uses the OAuth Proxy pattern to bridge Azureβs traditional OAuth with MCPβs authentication requirements. FastMCP validates Azure JWTs against your applicationβs client_id.
Configuration
Prerequisites
Before you begin, you will need:- An Azure Account with access to create App registrations
- Your FastMCP serverβs URL (can be localhost for development, e.g.,
http://localhost:8000) - Your Azure tenant ID (found in Azure Portal under Microsoft Entra ID)
Step 1: Create an Azure App Registration
Create an App registration in Azure Portal to get the credentials needed for authentication:Navigate to App registrations
Go to the Azure Portal and navigate to Microsoft Entra ID β App registrations.Click βNew registrationβ to create a new application.
Configure Your Application
Fill in the application details:
- Name: Choose a name users will recognize (e.g., βMy FastMCP Serverβ)
- Supported account types: Choose based on your needs:
- Single tenant: Only users in your organization
- Multitenant: Users in any Microsoft Entra directory
- Multitenant + personal accounts: Any Microsoft account
- Redirect URI: Select βWebβ and enter your server URL +
/auth/callback(e.g.,http://localhost:8000/auth/callback)
-
Expose an API: Configure your Application ID URI and define scopes
- Go to Expose an API in the App registration sidebar.
- Click Set next to βApplication ID URIβ and choose one of:
- Keep the default
api://{client_id} - Set a custom value, following the supported formats (see Identifier URI restrictions)
- Keep the default
- Click Add a scope and create a scope your app will require, for example:
- Scope name:
read(orwrite, etc.) - Admin consent display name/description: as appropriate for your org
- Who can consent: as needed (Admins only or Admins and users)
- Scope name:
-
Configure Access Token Version: Ensure your app uses access token v2
- Go to Manifest in the App registration sidebar.
- Find the
requestedAccessTokenVersionproperty and set it to2: - Click Save at the top of the manifest editor.
In FastMCPβs
AzureProvider, set identifier_uri to your Application ID URI (optional; defaults to api://{client_id}) and set required_scopes to the unprefixed scope names (e.g., read, write). During authorization, FastMCP automatically prefixes scopes with your identifier_uri.Create Client Secret
After registration, navigate to Certificates & secrets in your appβs settings.
- Click βNew client secretβ
- Add a description (e.g., βFastMCP Serverβ)
- Choose an expiration period
- Click βAddβ
Step 2: FastMCP Configuration
Create your FastMCP server using theAzureProvider, which handles Azureβs OAuth flow automatically:
server.py
Important: The
tenant_id parameter is REQUIRED. Azure no longer supports using βcommonβ for new applications due to security requirements. You must use one of:- Your specific tenant ID: Found in Azure Portal (e.g.,
08541b6e-646d-43de-a0eb-834e6713d6d5) - βorganizationsβ: For work and school accounts only
- βconsumersβ: For personal Microsoft accounts only
Important: The
required_scopes parameter is REQUIRED and must include at least one scope. Azureβs OAuth API requires the scope parameter in all authorization requests - you cannot authenticate without specifying at least one scope. Use the unprefixed scope names from your Azure App registration (e.g., ["read", "write"]). These scopes must be created under Expose an API in your App registration.Scope Handling
FastMCP automatically prefixesrequired_scopes with your identifier_uri (e.g., api://your-client-id) since these are your custom API scopes. Scopes in additional_authorize_scopes are sent as-is since they target external resources like Microsoft Graph.
required_scopes β Your custom API scopes, defined in Azure βExpose an APIβ:
| You write | Sent to Azure | Validated on tokens |
|---|---|---|
mcp-read | api://xxx/mcp-read | β |
my.scope | api://xxx/my.scope | β |
openid | openid | β (OIDC scope) |
api://xxx/read | api://xxx/read | β |
additional_authorize_scopes β External scopes (e.g., Microsoft Graph) for server-side use:
| You write | Sent to Azure | Validated on tokens |
|---|---|---|
User.Read | User.Read | β |
Mail.Send | Mail.Send | β |
offline_access is automatically included to obtain refresh tokens. FastMCP manages token refreshing automatically.Why arenβt
additional_authorize_scopes validated? Azure issues separate tokens per resource. The access token FastMCP receives is for your APIβGraph scopes arenβt in its scp claim. To call Graph APIs, your server uses the upstream Azure token in an on-behalf-of (OBO) flow.OIDC scopes (
openid, profile, email, offline_access) are never prefixed and excluded from validation because Azure doesnβt include them in access token scp claims.Testing
Running the Server
Start your FastMCP server with HTTP transport to enable OAuth flows:Testing with a Client
Create a test client that authenticates with your Azure-protected server:test_client.py
- Your browser will open to Microsoftβs authorization page
- Sign in with your Microsoft account (work, school, or personal based on your tenant configuration)
- Grant the requested permissions
- After authorization, youβll be redirected back
- 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.
Production Configuration
New in version2.13.0
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.Token Verification Only (Managed Identity)
New in version2.15.0
For deployments where your server only needs to validate incoming tokens β such as Azure Container Apps with Managed Identity β use AzureJWTVerifier with RemoteAuthProvider instead of the full AzureProvider.
This pattern is ideal when:
- Your infrastructure handles authentication (e.g., Managed Identity)
- You donβt need the OAuth proxy flow (no
client_secretrequired) - You just need to verify that incoming Azure AD tokens are valid
server.py
AzureJWTVerifier handles Azureβs scope format automatically. You write scope names exactly as they appear in Azure Portal under Expose an API (e.g., access_as_user). The verifier validates tokens using the short-form scopes that Azure puts in the scp claim, while advertising the full URI scopes (e.g., api://your-client-id/access_as_user) in OAuth metadata so MCP clients know what to request.
For Azure Government, pass
base_authority="login.microsoftonline.us" to AzureJWTVerifier.
