GeezerVison is showing github.com — Auth for MCP - Starlette middleware vs. OAuthAuthorizationServerProvider · Issue #702 · modelcontextprotocol/python-sdk
Auth for MCP - Starlette middleware vs. OAuthAuthorizationServerProvider #702DescriptionThere has been some discussion in this repo and in the TypeScript MCP repo regarding authentication with MCP servers.
The Python SDK includes an OAuthAuthorizationServerProvider example for implementing authentication.
What was the motivation behind introducing this? It seems that authentication could be implemented more directly—and in my opinion, more simply—using Starlette middleware. Additionally, OAuthAuthorizationServerProvider appears to assume user input as part of the flow, whereas MCP servers will often act as backend resource servers without direct user interaction. Reacted by Hristo Stavrev, Ravi Madabhushi, Chien Hoang, Lim Kevin CHAO, djordjemapp, Marcelo Trylesinski, Ryan Kanno and Fred Activityravibits commented on May 17, 2025 @Westerby I think you are right.
Based on some of the routes being bootstrapped as part of OAuthAuthorizationServiceProvider, like /.well-known/oauth-authorization-server in routes.py#94, I think the fundamental issue behind this design is assuming that the MCP Server is also responsible to act as an authorization server;
Based on the latest draft spec published here, the MCP Server should only be responsible for indicating where to find the authorization server details and also to expose the protected resource metadata information based on the authorization server details.
I would recommend the following changes to the FastMCP interface to the following:
server = FastMCP('My MCP Server', auth=AuthSettings(issuer_url='https://auth.server.com',resource='https://mcp.server.com', default_scopes=['profile','openid'])
Through this constructor, FastMCP can bootstrap the following routes and middleware:
-
/.well-known/oauth-protected-resource and should return the following:
{
"resource": "https://mcp.server.com",
"authorization_servers": "https://auth.server.com",
"bearer_methods_supported": ["header", "body"],
"scopes_supported":["profile", "opened"]
}
-
MCP Clients are supposed to pick up the authorization server details from https://auth.server.com/.well-known/oauth-authorization-server to figure out the registration endpoint, authorization end point and token endpoint and the MCP Server has no role to play here.
Rodriguespn commented on May 20, 2025 I completely agree with your solution here, @ravibits. I’ve been working on adding authentication to the SingleStore MCP server over the past few weeks, and it’s been quite challenging. Our MCP server won’t be hosted at the same URL as the auth service, and we’re using an internal authentication system.
The current MCP setup works well for local servers that can act as both the auth and resource servers—since we can open a browser UI for user authentication. But this doesn’t scale to enterprise use cases, where remote MCP servers make that flow unfeasible. We really need the ability to decouple the auth and resource servers—or at least support that option.
Does anyone have an example of a Python-based MCP server that uses a third-party auth service for authentication? I’d really appreciate any pointers. Reacted by Pedro Azevedo, Joseph Van Boxtel and djordjemapp djordjemapp commented on Jun 4, 2025 Rodriguespn commented on Jun 5, 2025
Any updates on this guys?
I have been trying to do the same, Third-Party AS and my MCP server...
As you already said, the impl look like MCP should be AS also, which is strange. One more idea occurs to me, to use API_KEY from Claude Desktop AI app, but that is also somehow not explained and not clear to me.
FastMCP requires OAuthAuthorizationServerProvider....
Here it says it is possible but there is no example :)
https://auth0.com/blog/an-introduction-to-mcp-and-authorization/#:~:text=Authorization%20with%20API%20keys%20and%20secrets
At the moment, it's not possible to fully delegate the authorization flow to a third-party Authorization Server using the OAuthProvider from the Python SDK. The OAuthProvider sets up and serves the following endpoints directly from your MCP server:
This setup means the current implementation assumes that your MCP server acts as both the Authorization Server (AS) and the Resource Server (RS), which indeed limits flexibility when trying to integrate a third-party AS.
If your goal is to delegate authorization to an external provider, the most viable approach for now is to have your MCP server act as a proxy between the client and your third-party authorization server. That is, MCP would forward client requests to the third-party AS, then pass the responses back to the client. This pattern allows you to bridge the existing MCP behavior with your external auth system. Reacted by Julius and KimMinjeong bojanbg commented on Jul 30, 2025
Does anyone have an example of a Python-based MCP server that uses a third-party auth service for authentication? I’d really appreciate any pointers.
I use FastMCP where I serve a custom /.well-known/oauth-protected-resource route returning the following:
{
"resource": "<mcp_server_path>",
"authorization_servers": ["<keycloak_server_path>"],
"bearer_methods_supported": ["header"]
}
Using MCP Inspector, this works successfully to authenticate using the external Keycloak server (with some workarounds for CORS issues). felixweinberger commented on Oct 7, 2025 Potentially a candidate for improved documentation on auth usage with python SDK. Reacted by Helmut Hoffer von Ankershoffen né Oertel sivajeetsabdakar commented on Jun 12, 2026 Hi, I’d like to work on a docs-focused PR for this issue.
Based on the discussion, I’m thinking of keeping the scope limited to documentation/examples rather than changing the auth API:
- clarify when
OAuthAuthorizationServerProvider is appropriate
- explain the MCP server-as-resource-server pattern with an external Authorization Server
- document how Starlette middleware/custom routes can be used for simpler auth cases
- add a small example for serving
/.well-known/oauth-protected-resource, similar to the Keycloak/external AS setup mentioned above
- call out current limitations around fully delegating the OAuth flow to a third-party Authorization Server
is this scope aligned before I start? maxisbey commented on Jul 24, 2026 Thanks for the report. This has since been addressed on main as part of the v2 work (see #982). Closing this as part of a wider backlog cleanup around the v2 release. If it's still relevant, feel free to reopen.
AI Disclaimer
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|