OAuth: Client not following RFC 9728 discovery flow, constructs incorrect authorization URLs

[austinlparker]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

macOS

Kiro Version

Kiro CLI (latest)

Bug Description

Kiro is not properly implementing OAuth 2.0 Protected Resource discovery (RFC 9728) when connecting to MCP servers with OAuth authentication. Instead of following the discovery flow to find the authorization server and endpoints, Kiro hardcodes assumptions about the URL structure.

What Kiro is doing (incorrect):

1. Takes the MCP server URL (e.g., https://mcp.honeycomb.io)
2. Appends /authorize to create: https://mcp.honeycomb.io/authorize
3. Opens this URL in the browser → 404 error

What Kiro should do (per RFC 9728):

1. Fetch https://mcp.honeycomb.io/.well-known/oauth-protected-resource
2. Extract authorization_servers[0] → https://ui.honeycomb.io
3. Fetch https://ui.honeycomb.io/.well-known/oauth-authorization-server
4. Extract authorization_endpoint → https://ui.honeycomb.io/oauth/authorize
5. Open the correct authorization URL

Steps to Reproduce

1. Configure Honeycomb's MCP server in ~/.kiro/settings/mcp.json:

{
  "mcpServers": {
    "honeycomb": {
      "url": "https://mcp.honeycomb.io",
      "type": "http"
    }
  }
}

2. Attempt to connect to the Honeycomb MCP server in Kiro
3. When prompted to authenticate, click "Open" to authorize
4. Browser opens to: https://mcp.honeycomb.io/authorize?... → 404 Not Found

Expected Behavior

Browser should open to the correct authorization endpoint discovered via OAuth metadata:

https://ui.honeycomb.io/oauth/authorize?response_type=code&client_id=...

Server Metadata (Verified Correct)

Protected Resource Metadata (https://mcp.honeycomb.io/.well-known/oauth-protected-resource):

{
  "resource": "https://mcp.honeycomb.io/mcp",
  "authorization_servers": ["https://ui.honeycomb.io"],
  "scopes_supported": ["mcp:read", "mcp:write"],
  "bearer_methods_supported": ["header"]
}

Authorization Server Metadata (https://ui.honeycomb.io/.well-known/oauth-authorization-server):

{
  "issuer": "https://ui.honeycomb.io",
  "authorization_endpoint": "https://ui.honeycomb.io/oauth/authorize",
  "token_endpoint": "https://ui.honeycomb.io/oauth/token",
  "registration_endpoint": "https://ui.honeycomb.io/oauth/register",
  ...
}

Root Cause

Kiro appears to be hardcoding the authorization URL construction instead of implementing the OAuth 2.0 discovery flow. This breaks when:

• The authorization server is on a different domain than the MCP server
• The authorization endpoint is not at /authorize (e.g., /oauth/authorize)

Conversation ID

No response

Additional Context

References:

• RFC 9728: OAuth 2.0 Protected Resource Metadata
• RFC 8414: OAuth 2.0 Authorization Server Metadata

Related Issues:

• MCP: Unable to authenticate with servers that contain query parameters #3681 - Similar issue with query parameter encoding in OAuth URLs
• Streamable HTTP / DCR not supported? Error: Failed to connect to MCP server "semilattice": token_endpoint_auth_method: Input should be 'none' or 'client_secret_post' #3908 - OAuth validation errors with MCP servers

This bug affects any MCP server that:

• Hosts the authorization server on a different domain than the resource server
• Uses a non-standard authorization endpoint path

[austinlparker]

As a followup, this works in MCP Inspector. Here's the results of the first three steps --

Metadata Discovery

  "resource": "https://mcp.honeycomb.io/mcp",
  "authorization_servers": [
    "https://ui.honeycomb.io"
  ],
  "scopes_supported": [
    "mcp:read",
    "mcp:write"
  ],
  "bearer_methods_supported": [
    "header"
  ]
}

AS Metadata Response

{
  "issuer": "https://ui.honeycomb.io",
  "authorization_endpoint": "https://ui.honeycomb.io/oauth/authorize",
  "token_endpoint": "https://ui.honeycomb.io/oauth/token",
  "registration_endpoint": "https://ui.honeycomb.io/oauth/register",
  "scopes_supported": [
    "mcp:read",
    "mcp:write"
  ],
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "none",
    "client_secret_basic",
    "client_secret_post"
  ],
  "introspection_endpoint": "https://ui.honeycomb.io/oauth/introspect",
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ]
}

Client Registration

{
  "redirect_uris": [
    "http://localhost:6274/oauth/callback/debug"
  ],
  "token_endpoint_auth_method": "none",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "client_name": "MCP Inspector",
  "scope": "mcp:read mcp:write",
  "client_id": "hcaoc_01kabqm0akd3xdaex6jgzg7ncm",
  "client_id_issued_at": 1763477946,
  "client_secret_expires_at": 0
}

AS URL

https://ui.honeycomb.io/oauth/authorize?response_type=code&client_id=hcaoc_01kabqm0akd3xdaex6jgzg7ncm&code_challenge=pdEOUJBcD0TXLmFvkj_TIqRvr0Yah7EO3T-BgOoD9fo&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback%2Fdebug&state=18c2b357d73cae77e9c2ccd62d9581b393bbe121fe889f6a16884d96b2d9e253&scope=mcp%3Aread+mcp%3Awrite&resource=https%3A%2F%2Fmcp.honeycomb.io%2Fmcp

[AnilMaktala]

Hey @austinlparker, Thanks for raising this. I can repro the issue and marking this as a bug for the team to evaluate further.

[mariswa]

There is also proposed OAuth configuration: aws/amazon-q-developer-cli#2921

[lizthegrey]

@AnilMaktala @Yanacek any luck chasing this up? thanks.

[AnilMaktala]

@lizthegrey, I was able to connect successfully with the following configuration. Would you mind testing this on your end as well and letting me know if you have the same result?

   "honeycomb": {
      "url": "https://mcp.honeycomb.io/mcp",
      "disabled": false
    },

[Yanacek]

@AnilMaktala this is tagged as a Kiro CLI bug and I also have this problem in Kiro CLI. When I type /mcp I get this, which also points to the /authorize url which is a 404, vs this /oauth/authorize.