Discovery metadata omits refresh_token grant despite /oauth/token support

[caiopavanelli]

Problem

Proxy-mode MCP clients (e.g. Claude Desktop, Codex) disconnect after the access token expires (~1 hour), even when the upstream IdP issued a refresh token.

POST /oauth/token already supports grant_type=refresh_token (see #17 and #18). OAuth 2.0 Authorization Server Metadata (RFC 8414) and the MCP discovery responses only advertise:

"grant_types_supported": ["authorization_code"]

on:

• GET /oauth/metadata (HandleMetadata)
• GET /.well-known/openid-configuration (HandleOIDCDiscovery)
• GetAuthorizationServerMetadata() (native and proxy branches)

POST /oauth/register (HandleRegister) already returns both authorization_code and refresh_token in grant_types, so discovery and registration are inconsistent.

Conformant clients that read grant_types_supported before attempting silent renewal may skip the refresh flow and force full re-authentication on every access-token expiry.

Expected behavior

All authorization-server metadata endpoints should include refresh_token in grant_types_supported when the token endpoint supports it, matching /oauth/register and /oauth/token behavior.

Proposed fix

Add refresh_token to grant_types_supported in the four discovery code paths in metadata.go. No handler changes required.

Notes

• Obtaining a refresh token from the upstream IdP still requires the appropriate scope (e.g. offline_access for Okta/Azure) via Config.Scopes / OIDC_SCOPES. This issue is only about advertising the grant type to clients.
• Related: Support refresh tokens #17, Support refresh tokens #18

Environment

• Mode: proxy
• Library: oauth-mcp-proxy (main / v1.2.0)

[m13v]

the /register vs discovery mismatch is the trap: clients caching the register response see refresh_token, discovery-readers don't.