MCP OAuth authentication fails with GitHub remote MCP server

[salma-marei]

While connecting NetClaw to GitHub's remote MCP server, I encountered four OAuth compatibility issues. Each issue became visible after resolving the previous one.

1. Incorrect metadata discovery for path-bearing issuers

GitHub's authorization server issuer is:

https://github.com/login/oauth

NetClaw currently appends the well-known metadata path directly to the issuer:

https://github.com/login/oauth/.well-known/oauth-authorization-server

This returns 404.

For path-bearing issuers, RFC 8414 requires the path-inserted form:

https://github.com/.well-known/oauth-authorization-server/login/oauth

2. No support for OAuth client secrets

GitHub OAuth Apps require a client secret during token exchange, but NetClaw currently has no configuration field for one.

3. No CLI support for configuring the client secret

Even with client-secret support in the configuration model, there is currently no safe way to provide it through netclaw mcp add.

4. GitHub token response is not requested as JSON

GitHub's token endpoint may return a form-encoded response by default, while the SDK expects JSON. This causes token parsing to fail during authorization.

Proposed Fix

Update the MCP OAuth flow to:

• Use RFC 8414 path-inserted metadata discovery for path-bearing issuers, with the existing append form as a fallback for compatibility.
• Add an optional OAuthClientSecret using SensitiveString, stored encrypted in secrets.json.
• Add a --client-secret option to netclaw mcp add that writes the value to the encrypted secrets store rather than netclaw.json.
• Send Accept: application/json with OAuth token requests so token responses can be parsed correctly by the SDK.

Tests should cover both metadata URL forms, client-secret configuration/storage, and token request headers.

Related

#2123 also identifies the lack of OAuth client-secret support. This issue additionally covers the RFC 8414 metadata discovery issue and GitHub token response handling.

[Aaronontheweb]

thanks @salma-marei - this actually helps me understand #2123 better. My original solution was to work around that by front-ending Dropbox's MCP server (the one I struggled with on that issue) with my own proxy that worked via dynamic OAuth client registration, but it's clear to me now that I overlooked a built-in solution that might work. Let me ponder this and get back to you with a proposal.

Absolutely great and helpful find!

[Aaronontheweb]

I opened #2167 for the focused token-response workaround.

It adds Accept: application/json only to form-encoded OAuth token requests. A programmable fake MCP OAuth server proves the GitHub-style response negotiation and successful client publication.

This fix will ship in Netclaw 0.27.0-beta.4.

The PR does not add static client-secret configuration. That broader OAuth fix is next.

[Aaronontheweb]

The permanent confidential-client fix is now in #2169.

It adds encrypted OAuthClientSecret configuration and the --client-secret CLI option.
It passes the configured identity to the SDK for code exchange and refresh.

The programmable OAuth server proves code exchange, restart refresh, secret rotation, and no dynamic client registration.

PR #2167 shipped in Netclaw 0.27.0-beta.4.
That release shipped before #2169 was ready.
PR #2169 now targets the next Netclaw 0.27 prerelease.

It does not change the anonymous-discovery flow from #2123.