fix: implement RFC 8414 compliant OAuth metadata discovery #262
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Smithery.ai servers use non-standard OAuth metadata paths that don't match the current implementation. Per RFC 8414 Section 3.1, when the authorization server URL contains a path, the well-known path should be inserted between host and path, not appended after. Changes: - Add buildRFC8414MetadataURLs() to construct compliant metadata URLs - Add discoverAuthServerMetadataWithFallback() to try multiple paths - Try RFC 8414 path first, fall back to legacy path for compatibility - Include all attempted URLs in error messages for debugging - Add comprehensive unit tests for both Smithery and legacy servers Example URL transformations: - https://auth.smithery.ai/googledrive → https://auth.smithery.ai/.well-known/oauth-authorization-server/googledrive Fixes #251 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Deploying mcpproxy-docs with
|
| Latest commit: |
caffe5e
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ce1e47eb.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://fix-251-smithery-oauth-disco.mcpproxy-docs.pages.dev |
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 21112333005 --repo smart-mcp-proxy/mcpproxy-go
|
Smithery and similar servers use separate domains for MCP and OAuth: - MCP Server: server.smithery.ai/googledrive - Auth Server: auth.smithery.ai/googledrive Previously, OAuth metadata discovery used the MCP server URL directly, causing DCR to fail with 404 because metadata is on the auth server. Changes: - Add DiscoverAuthServerURL() to get auth server from Protected Resource Metadata (RFC 9728) - Add FindWorkingMetadataURL() to validate which metadata URL works - Add base URL fallback to BuildRFC8414MetadataURLs() for Cloudflare-style servers that host metadata at root level - Update createOAuthConfigInternal() to discover auth server before constructing OAuth metadata URLs - Update mcp-go to v0.44.0-beta.2 Fixes #251 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
technicalpickles
pushed a commit
to technicalpickles/mcpproxy-go
that referenced
this pull request
Jan 21, 2026
…-proxy#262) * fix: implement RFC 8414 compliant OAuth metadata discovery (smart-mcp-proxy#251) Smithery.ai servers use non-standard OAuth metadata paths that don't match the current implementation. Per RFC 8414 Section 3.1, when the authorization server URL contains a path, the well-known path should be inserted between host and path, not appended after. Changes: - Add buildRFC8414MetadataURLs() to construct compliant metadata URLs - Add discoverAuthServerMetadataWithFallback() to try multiple paths - Try RFC 8414 path first, fall back to legacy path for compatibility - Include all attempted URLs in error messages for debugging - Add comprehensive unit tests for both Smithery and legacy servers Example URL transformations: - https://auth.smithery.ai/googledrive → https://auth.smithery.ai/.well-known/oauth-authorization-server/googledrive Fixes smart-mcp-proxy#251 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: discover auth server from PRM for separate domain OAuth servers Smithery and similar servers use separate domains for MCP and OAuth: - MCP Server: server.smithery.ai/googledrive - Auth Server: auth.smithery.ai/googledrive Previously, OAuth metadata discovery used the MCP server URL directly, causing DCR to fail with 404 because metadata is on the auth server. Changes: - Add DiscoverAuthServerURL() to get auth server from Protected Resource Metadata (RFC 9728) - Add FindWorkingMetadataURL() to validate which metadata URL works - Add base URL fallback to BuildRFC8414MetadataURLs() for Cloudflare-style servers that host metadata at root level - Update createOAuthConfigInternal() to discover auth server before constructing OAuth metadata URLs - Update mcp-go to v0.44.0-beta.2 Fixes smart-mcp-proxy#251 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #251 - OAuth discovery fails for Smithery servers due to non-standard metadata path.
Smithery.ai servers use RFC 8414 compliant OAuth metadata paths, but mcpproxy was using a non-compliant path. Per RFC 8414 Section 3.1, when the authorization server URL contains a path, the well-known path should be inserted between host and path:
https://auth.smithery.ai/googledrivehttps://auth.smithery.ai/.well-known/oauth-authorization-server/googledrive✅https://auth.smithery.ai/googledrive/.well-known/oauth-authorization-server❌Changes
buildRFC8414MetadataURLs(): Constructs compliant metadata URLs per RFC 8414 Section 3.1discoverAuthServerMetadataWithFallback(): Tries multiple discovery paths with fallbackTest plan
buildRFC8414MetadataURLs()with various URL formatsdiscoverAuthServerMetadataWithFallback()with both path stylesNote on DCR panic
During testing, I discovered a separate issue where the manual
auth logincommand fails with a nil pointer dereference during Dynamic Client Registration (DCR). This is a pre-existing bug unrelated to the OAuth discovery path fix. The background OAuth flow works correctly - the DCR panic only affects the CLI login command. This should be tracked as a separate issue.🤖 Generated with Claude Code