Claude custom connector with Google sign-in: fixing redirect_uri_mismatch

Why are there two redirect URIs?

With FastMCP's Google provider your MCP server is an OAuth proxy. claude.ai signs in to your server, and your server signs in to Google. Each leg has its own redirect:

Leg	Redirect URI	Registered where
claude.ai to your server	https://claude.ai/api/mcp/auth_callback	Allowed by your server (code below)
Your server to Google	https://your-server/auth/callback	Google Cloud Console, on the client your server uses

Mixing them up is the most common mistake in public bug reports: people register Claude's callback at Google, then wonder why Google rejects their own.

What caused my redirect_uri_mismatch?

I hit this today on a new connector. The server log showed claude.ai reaching the consent page and the server redirecting to Google, and Google answering with the mismatch. The callback was correct; the client was not. The connector had been configured with one Google OAuth client while the redirect URI had been added to another one in the console. Pointing the server at the client that actually carried the URI fixed it in one restart. So check the client ID in your server's settings against the one you edited, character by character, before anything else.

The server side, in FastMCP

from fastmcp.server.auth.providers.google import GoogleProvider

CLAUDE_REDIRECT_URIS = [
    "https://claude.ai/api/mcp/auth_callback",
    "https://claude.com/api/mcp/auth_callback",
]

auth = GoogleProvider(
    client_id=env["GOOGLE_CLIENT_ID"],          # the client that carries your callback
    client_secret=env["GOOGLE_CLIENT_SECRET"],
    base_url="https://your-server",             # Google returns to base_url + /auth/callback
    required_scopes=["openid", "https://www.googleapis.com/auth/userinfo.email"],
    jwt_signing_key=env["JWT_SIGNING_KEY"],
    allowed_client_redirect_uris=CLAUDE_REDIRECT_URIS,  # only Claude may receive codes
)

The last line matters for security as much as for function. Without an allow-list, a phishing client could register itself through dynamic client registration and receive an authorisation code for your account. Add an email allow-list on top, so a valid Google sign-in from anyone else is still refused.

Does the reverse proxy need anything special?

Yes. The OAuth flow uses more paths than /mcp: /authorize, /token, /register, /auth/callback, /consent and the /.well-known/ metadata. If your Nginx only forwards /mcp, claude.ai fails before Google is even involved. I forward the whole host to the MCP server and let it return 404 for anything it does not serve.

A checklist that finds the fault in minutes

1. Unauthenticated POST /mcp returns 401. If you get 404 or 502, the proxy is wrong.
2. GET /.well-known/oauth-authorization-server returns 200 with your public base URL in it.
3. The Google client in your server's settings is the one you edited in the console.
4. That client's authorised redirect URIs contain exactly https://your-server/auth/callback, scheme and host included.
5. You waited a few minutes after saving; Google applies changes with a short delay.
6. Your server log shows /authorize, then /consent, then a 302. That proves the claude.ai side works and the fault is at Google.

About the author. Muhammad Tayyab Ilyas is an Applied AI & Solutions Engineer in Barcelona who builds and operates MCP servers, multi-agent systems and the infrastructure under them. His connectors run behind Google sign-in with a single allowed account.