Update (September 21, 2025): Original post removed; successful solution in first comment. Leaving postmortem for posterity.
tl;dr –
ChatGPT is stricter than Claude about the MCP-specific discovery path.
If your connector suddenly claims “Failed to resolve OAuth client,” double-check every /.well-known/… rule in front of the MCP service.
Update (September 21, 2025): The bug was in my reverse-proxy. ChatGPT asks for
/.well-known/oauth-authorization-server/mcp, but my NGINX rule rewrote that path
to/mcp/.well-known/oauth-authorization-serverbefore proxying to the MCP service.
That mismatch meant ChatGPT received an empty discovery document and defaulted to
oauth_client_params: null. Fixing theproxy_passtarget so it relays the request
verbatim restored the OAuth client metadata and the connector now links reliably.
What looked like ChatGPT “forgetting” my client id was really an NGINX routing error
on my end. Claude continued to work because it only ever called the top-level discovery
endpoint, while ChatGPT asked for the MCP-specific variant (/.well-known/.../mcp) that I
was accidentally rewriting. Once I stopped mangling that path, ChatGPT immediately started
resolving the metadata and the connector succeeds end-to-end.
ChatGPT users could not start OAuth because the discovery doc I served them did not
include the MCP section. The moment I corrected the proxy rule, new ChatGPT sessions
negotiated oauth_client_params normally and existing users could reconnect without code
changes.
Expected: ChatGPT should fetch my discovery document, see the mcp.client_id, and
proceed with PKCE just like Claude.
Pre-fix Actual: ChatGPT hit https://dexter.cash/.well-known/oauth-authorization- server/mcp, received an empty payload (because I proxied to the wrong upstream path), and
bailed out with Failed to resolve OAuth client.
Post-fix Actual: With the corrected proxy target, ChatGPT receives the full metadata,
populates oauth_client_params, and completes the OAuth handshake without issue.
# Broken: appended "/mcp" before the well-known path and dropped the content ChatGPT needs
# location = /.well-known/oauth-authorization-server/mcp {
# proxy_pass http://127.0.0.1:3930/mcp/.well-known/oauth-authorization-server;
# }
# Working: relay the request verbatim to the MCP service
location = /.well-known/oauth-authorization-server/mcp {
proxy_pass http://127.0.0.1:3930/.well-known/oauth-authorization-server/mcp;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
add_header Cache-Control "no-store" always;
}
$ curl https://dexter.cash/.well-known/oauth-authorization-server/mcp | jq '{issuer,
authorization_endpoint, token_endpoint, mcp}'
{
"issuer": "https://dexter.cash/mcp",
"authorization_endpoint": "https://dexter.cash/mcp/authorize",
"token_endpoint": "https://dexter.cash/mcp/token",
"mcp": {
"client_id": "cid_a859560609a6448aa2f3a1c29f6ab496",
"redirect_uri": "https://dexter.cash/mcp/callback"
}
}
ChatGPT stopped returning oauth_client_params: null as soon as this document was
available.
[dexter-api] [connector/oauth/authorize] issued request { clientId:
'cid_a859560609a6448aa2f3a1c29f6ab496', ... }
[dexter-api] [connector/oauth/exchange] issued code { codePreview: 'code_b65a11d', ... }
[dexter-mcp] [oauth] token accepted { user: '…', claims: { sub: '…', email: '…' } }
This is the same healthy log sequence I see in Claude, now mirrored in ChatGPT.
No bug, just a misconfiguration – one that I suspect a lot of people will run into.
The fix was to update nginx so that /.well-known/oauth-authorization-server/mcp proxies straight through to the MCP service without mutating the path. After reloading, ChatGPT picked up the client id automatically and the connector is back to normal.
I have had root canals that were more fun than diagnosing this, but the final result is awesome and worth it. I can’t believe I now have my own maxed-out MCP ready for anyone to simply add without the need for generating API keys; no perpetual login flows to deal with; no frontend to build from scratch; is this what nirvana is like?
If you are having trouble getting it working, I highly recommend the resources below. Otherwise, until OpenAI documentation improves (a lot), you are swimming upstream without a paddle unless you are one of the world’s foremost experts in OAuth.
P.S. – If you are using Vercel/Netlify, turn around now and don’t look back. It might connect for you in isolated instances, and it may even seem fine at first, but beware – MCP OAuth will not play nicely. Among other issues, your users will constantly be forced to Reconnect among other sorts of trouble. AWS remains the GOAT.
This topic was automatically closed after 24 hours. New replies are no longer allowed.