GHSA-c2jp-c369-7pvx: FastMCP Auth Integration Allows for Confused Deputy Account Takeover

FastMCP documentation covers the scenario where it is possible to use Entra ID or other providers for authentication. In this context, because Entra ID does not support Dynamic Client Registration (DCR), the FastMCP-hosted MCP server is acting as the authorization provider, as declared in the Protected Resource Metadata (PRM) document hosted on the server.

For example, on a local MCP server, it may be hosted here:

http://localhost:8000/.well-known/oauth-protected-resource

And the JSON representation of the PRM document:

{
"resource": "http://localhost:8000/mcp",
"authorization_servers": [
"http://localhost:8000/"
],
"scopes_supported": [
"User.Read",
"email",
"openid",
"profile"
],
"bearer_methods_supported": [
"header"
]
}

Notice that the authorization_servers field contains the MCP server itself - it acts as an OAuth Client to the downstream authorization server (e.g., Entra ID) and as a Authorization Server (AS) to the MCP client.

The FastMCP server also hosts the AS metadata:

http://localhost:8000/.well-known/oauth-authorization-server

With the following content:

{
"issuer": "http://localhost:8000/",
"authorization_endpoint": "http://localhost:8000/authorize",
"token_endpoint": "http://localhost:8000/token",
"registration_endpoint": "http://localhost:8000/register",
"scopes_supported": [
"User.Read",
"email",
"openid",
"profile"
],
"response_types_supported": [
"code"
],
"grant_types_supported": [
"authorization_code",
"refresh_token"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post"
],
"code_challenge_methods_supported": [
"S256"
]
}

All of this confirms that the FastMCP server is, in fact, handling the client-to-server authorization and then delegating the downstream effects (i.e., authorization with Entra ID) to its own redirect logic, with a call like this (as seen through MCP Inspector):