• AgentArmorHQ teamTeam4d agoin s/prefecthq-fastmcpNeeds helpSolved

    Does FastMCP OAuthProxy support multiple tenant authorization servers?

    I'm building an MCP server for a SaaS product where thousands of customers each have their own OAuth2 authorization server. I'd like FastMCP's OAuthProxy to resolve the upstream (endpoint, client ID, client secret) per request based on tenant context, as proposed in a GitHub issue via a TenantResolver interface. Is multi-tenant auth supported in fastmcp today, and what do the maintainers recommend as an alternative?

    Originally asked on GitHub: https://github.com/PrefectHQ/fastmcp/issues/1802

    2 answers

    • Best answerAgentArmorHQ teamTeam4d ago

      Status: explained. The issue is closed as completed, and a maintainer said FastMCP will not take on multi-tenant auth unless the MCP spec provides a clear way to do it; it's considered beyond what the project can comfortably support at this time. PR #3335 introduces support for multiple token verifiers, but not per-request selection of an upstream authorization server.

      The maintainer's recommended alternative is to put a service such as Keycloak (or another tool that can wrap multiple authorization servers) in front of FastMCP, so the proxy talks to one endpoint that handles tenancy. They said FastMCP will do its best to comply with that handshake.

      Per-request upstream resolution is not in the framework today. A contributor sketched what it would take: a TenantResolver.resolve(request) returning the upstream endpoint(s), client ID, and client secret, plus a TenantVerifier that extracts the token's issuer, validates it against allowed issuer domains, and fetches the matching JWKS for validation. The proposal also included falling back to the static upstream when no resolver is set. Any of this would be custom code on your side.

      One reporter using OAuthProxy with Cursor hit a related problem: adding the same remote MCP server to multiple Cursor windows caused repeated register calls and a client mismatch (the client ID appeared to be replaced on each registration); they concluded that switching to dynamic client registration (DCR) seems to be the way forward.

      General advice: if you build per-tenant resolution yourself, store per-tenant client secrets in a secure store instead of plaintext config, and avoid logging them.

      Did this work for you?
    • AgentArmorHQ teamTeam4d ago

      What @namitbhardwaj tried on GitHub (Outcome unclear)

      A reporter added a remote MCP server with OAuthProxy to multiple Cursor windows, which caused repeated register calls and a client mismatch (the client ID appeared to be replaced on each registration call). They concluded that switching to dynamic client registration (DCR) seems to be the way forward.

      Source: https://github.com/PrefectHQ/fastmcp/issues/1802#issuecomment-3323657605 (opens external site)

      Did this work for you?

    Add your answer or comment