Remote MCP OAuth discovery fails without fallback to default endpoints

[otteydw]

Checks

• I have searched github.com/aws/amazon-q-developer-cli/issues and there are no duplicates of my issue
• I have run q doctor in the affected terminal session
• I have run q restart and replicated the issue again

Operating system

macOS 15.7.3 (24G419)

Expected behaviour

When connecting to a remote MCP server (Atlassian Rovo) that doesn't implement OAuth discovery metadata endpoints, Kiro CLI should fall back to the default OAuth endpoints as specified in the OAuth 2.0 specification. The connection should succeed using the standard default endpoints even when /.well-known/ discovery URLs return no valid configuration.

Actual behaviour

Kiro CLI attempts OAuth discovery at three different metadata endpoints:

• /.well-known/oauth-authorization-server/v1/sse
• /.well-known/openid-configuration/v1/sse
• /v1/sse/.well-known/openid-configuration

When all three discovery attempts fail to return valid OAuth configuration, Kiro CLI throws error -32002 "No authorization support detected" instead of falling back to default OAuth endpoints. This prevents connection to remote MCP servers that don't implement the optional discovery metadata endpoints.

Error message:

✗ atlassian-rovo has failed to load after 1.47 s

• Mcp error: -32002: No authorization support detected

Debug logs show the discovery attempts but no fallback behavior:

2026-02-05T15:01:10.291647Z DEBUG rmcp::transport::auth: discovery url: /.well-known/oauth-authorization-server/v1/sse
2026-02-05T15:01:10.460097Z DEBUG rmcp::transport::auth: discovery url: /.well-known/openid-configuration/v1/sse
2026-02-05T15:01:10.548232Z DEBUG rmcp::transport::auth: discovery url: /v1/sse/.well-known/openid-configuration
2026-02-05T15:01:11.049333Z ERROR chat_cli::cli::chat::tool_manager: Error loading server atlassian-rovo: McpError(ErrorData { code: ErrorCode(-32002), message: "No authorization support detected" })

Steps to reproduce

1. Configure a remote MCP server in agent config (e.g., ~/.kiro/agents/devops_agent_config.json):

  "atlassian-rovo": {
    "url": "https://mcp.atlassian.com/v1/mcp",
    "autoApprove": []
  }

2. Start Kiro CLI with the agent:

  kiro-cli chat --agent devops

3. Observe the error during MCP server initialization:

  ✗ atlassian-rovo has failed to load after 1.47 s
    - Mcp error: -32002: No authorization support detected

4. Check logs with KIRO_LOG_LEVEL=trace to see OAuth discovery attempts without fallback

Note: This issue appeared after a recent Kiro CLI update. The same configuration worked in the previous version.

Environment

<This will be visible to anyone. Do not include personal or sensitive information>

[q-details]
version = "1.25.0"
hash = "0bbf37c7a78548dfbca692ce537be01af1de624f"
date = "2026-02-04T22:41:02.85683Z (22h ago)"
variant = "full"

[system-info]
os = "macOS 15.7.3 (24G419)"
chip = "Apple M1 Pro"
total-cores = 8
memory = "32.00 GB"

[environment]
cwd = "/Users/USER"
cli-path = "/Users/USER"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.9"
terminal = "iTerm 2"
install-method = "unknown"

[env-vars]
PATH = "/opt/homebrew/opt/coreutils/libexec/gnubin:/opt/homebrew/opt/gnu-sed/libexec/gnubin:/Users/USER/.cargo/bin:/Users/USER/.rd/bin:/opt/homebrew/opt/mysql-client@8.0/bin:/Users/USER/.pyenv/plugins/pyenv-virtualenv/shims:/Users/USER/.pyenv/shims:/Users/USER/.pyenv/bin:/Users/USER/.cargo/bin:/Users/USER/.docker/bin:/Users/USER/.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Library/TeX/texbin:/usr/local/munki:/Applications/iTerm.app/Contents/Resources/utilities:/Users/USER/.local/bin:/Users/USER/ACLI:/Users/USER/.docker/bin:/Users/USER/go/bin:/Users/USER/opt/bin"
QTERM_SESSION_ID = "6519ee3ce01449dd822a9fff020bf7cb"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "1.25.0"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.googlecode.iterm2"

[clgtm]

We are seeing a similar issue. Perhaps resource_metadata is missing in WWW-Authenticate header -

Command:   authprobe scan --trace-failure --llm-max-tokens=1080 https://mcp.atlassian.com/v1/mcp
Scanning:  https://mcp.atlassian.com/v1/mcp
Scan time: Feb 10, 2026 15:38:14 UTC
Github:    https://github.com/authprobe/authprobe

Funnel
  [1] MCP probe (401 + WWW-Authenticate)      [+] PASS
        missing WWW-Authenticate/resource_metadata

  [2] MCP initialize + tools/list             [-] SKIP
        initialize -> 401 (non-JSON response) (auth required)

  [3] PRM fetch matrix                        [X] FAIL
        https://mcp.atlassian.com/.well-known/oauth-protected-resource -> 404
        https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp ->
        404
        PRM unreachable or unusable; OAuth discovery unavailable

  [4] Auth server metadata                    [-] SKIP
        no authorization_servers in PRM

  [5] Token endpoint readiness (heuristics)   [-] SKIP
        no token_endpoint in metadata

  [6] Dynamic client registration (RFC 7591)  [-] SKIP
        no registration_endpoint in metadata

Primary Finding (HIGH): AUTH_REQUIRED_BUT_NOT_ADVERTISED (confidence 1.00)
  Evidence:
      401/403 without WWW-Authenticate/resource_metadata
      no PRM endpoints returned valid metadata
      Auth appears required but OAuth discovery was not advertised. Next steps: add
      WWW-Authenticate + PRM for OAuth/MCP discovery, or document the required non-OAuth auth
      (e.g., SigV4).

┌───────────────────────┤ CALL TRACE ├───────────────────────┐
Call Trace Using: https://github.com/authprobe/authprobe

  ┌────────────┐                                                    ┌────────────┐
  │ authprobe  │                                                    │ MCP Server │
  └─────┬──────┘                                                    └─────┬──────┘
        │                                                                 │
        │ ╔═══ Step 1: MCP probe                    ═══════╪═══════════════════╗
        │  GET https://mcp.atlassian.com/v1/mcp
        │  Reason: 401 + WWW-Authenticate discovery
        │    Accept:  text/event-stream
        │    Host:    mcp.atlassian.com
        ├─────────────────────────────────────────────────────────────────►│
        │  401 Unauthorized
        │    Atl-Request-Id:                    90f18011-287c-4b68-823e-70de1643691a
        │    Atl-Traceid:                       90f18011287c4b68823e70de1643691a
        │    Cf-Ray:                            9cbcb13cafe1f820-PDX
        │    Content-Length:                    79
        │    Content-Type:                      application/json
        │    Date:                              Tue, 10 Feb 2026 15:38:13 GMT
        │    Ge-Edge-Trusted-Cloudflare-Proxy:  bWNwLWNsb3VkZmxhcmUK
        │    Nel:                               {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
        │    Report-To:                         {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
        │    Server:                            AtlassianEdge
        │    Server-Timing:                     atl-edge;dur=13,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
        │    Strict-Transport-Security:         max-age=63072000; preload
        │    Vary:                              Accept-Encoding
        │    Www-Authenticate:                  Bearer realm="OAuth", error="invalid_token", error_description="Missing or invalid access token"
        │    X-Content-Type-Options:            nosniff
        │    X-Xss-Protection:                  1; mode=block
        │◄─────────────────────────────────────────────────────────────────┤
        │                                                                  │
        │ ╔═══ Step 2: MCP initialize               ═══════╪═══════════════════╗
        │  POST https://mcp.atlassian.com/v1/mcp
        │  Reason: Step 2: MCP initialize + tools/list (initialize)
        │    Accept:                application/json, text/event-stream
        │    Content-Type:          application/json
        │    Host:                  mcp.atlassian.com
        │    Mcp-Protocol-Version:  2025-11-25
        ├─────────────────────────────────────────────────────────────────►│
        │  401 Unauthorized
        │    Atl-Request-Id:                    6260d19c-d19e-43b3-ad5d-5243f55c67c6
        │    Atl-Traceid:                       6260d19cd19e43b3ad5d5243f55c67c6
        │    Cf-Ray:                            9cbcb13cd82af820-PDX
        │    Content-Length:                    79
        │    Content-Type:                      application/json
        │    Date:                              Tue, 10 Feb 2026 15:38:13 GMT
        │    Ge-Edge-Trusted-Cloudflare-Proxy:  bWNwLWNsb3VkZmxhcmUK
        │    Nel:                               {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
        │    Report-To:                         {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
        │    Server:                            AtlassianEdge
        │    Server-Timing:                     atl-edge;dur=13,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
        │    Strict-Transport-Security:         max-age=63072000; preload
        │    Vary:                              Accept-Encoding
        │    Www-Authenticate:                  Bearer realm="OAuth", error="invalid_token", error_description="Missing or invalid access token"
        │    X-Content-Type-Options:            nosniff
        │    X-Xss-Protection:                  1; mode=block
        │◄─────────────────────────────────────────────────────────────────┤
        │                                                                  │
        │ ╔═══ Step 3: PRM Discovery                ═══════╪═══════════════════╗
        │  GET https://mcp.atlassian.com/.well-known/oauth-protected-resource
        │  Reason: Step 3: PRM fetch matrix
        │    Accept:  application/json
        │    Host:    mcp.atlassian.com
        ├─────────────────────────────────────────────────────────────────►│
        │  404 Not Found
        │    Atl-Request-Id:                    79e502a3-e1a2-40fd-a88e-dc043dc74f3b
        │    Atl-Traceid:                       79e502a3e1a240fda88edc043dc74f3b
        │    Cf-Ray:                            9cbcb13d1bb89873-PDX
        │    Content-Length:                    13
        │    Content-Type:                      text/plain; charset=UTF-8
        │    Date:                              Tue, 10 Feb 2026 15:38:13 GMT
        │    Ge-Edge-Trusted-Cloudflare-Proxy:  bWNwLWNsb3VkZmxhcmUK
        │    Nel:                               {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
        │    Report-To:                         {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
        │    Server:                            AtlassianEdge
        │    Server-Timing:                     atl-edge;dur=13,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
        │    Strict-Transport-Security:         max-age=63072000; preload
        │    Vary:                              Accept-Encoding
        │    X-Content-Type-Options:            nosniff
        │    X-Xss-Protection:                  1; mode=block
        │◄─────────────────────────────────────────────────────────────────┤
        │                                                                  │
        │  GET https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp
        │  Reason: Step 3: PRM fetch matrix
        │    Accept:  application/json
        │    Host:    mcp.atlassian.com
        ├─────────────────────────────────────────────────────────────────►│
        │  404 Not Found
        │    Atl-Request-Id:                    89d3baf3-55f7-4010-bc49-8cf9085a7acb
        │    Atl-Traceid:                       89d3baf355f74010bc498cf9085a7acb
        │    Cf-Ray:                            9cbcb13d48edf820-PDX
        │    Content-Length:                    13
        │    Content-Type:                      text/plain; charset=UTF-8
        │    Date:                              Tue, 10 Feb 2026 15:38:13 GMT
        │    Ge-Edge-Trusted-Cloudflare-Proxy:  bWNwLWNsb3VkZmxhcmUK
        │    Nel:                               {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
        │    Report-To:                         {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
        │    Server:                            AtlassianEdge
        │    Server-Timing:                     atl-edge;dur=13,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
        │    Strict-Transport-Security:         max-age=63072000; preload
        │    Vary:                              Accept-Encoding
        │    X-Content-Type-Options:            nosniff
        │    X-Xss-Protection:                  1; mode=block
        │◄─────────────────────────────────────────────────────────────────┤
        ▼                                                                  ▼

                                                                                                                                                                                                                                                                                                     
┌───────────────┤ FAILED TEST VERBOSE OUTPUT ├───────────────┐
== Step 3: PRM fetch matrix ==
> GET /.well-known/oauth-protected-resource HTTP/1.1
> Host: mcp.atlassian.com
> Accept: application/json
>
> (empty body)
< HTTP/2.0 404 Not Found
< Atl-Request-Id: 061d2fe2-4e01-4073-8434-a72d68434adb
< Atl-Traceid: 061d2fe24e0140738434a72d68434adb
< Cf-Ray: 9cbcb13d8c539873-PDX
< Content-Length: 13
< Content-Type: text/plain; charset=UTF-8
< Date: Tue, 10 Feb 2026 15:38:14 GMT
< Ge-Edge-Trusted-Cloudflare-Proxy: bWNwLWNsb3VkZmxhcmUK
< Nel: {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
< Report-To: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
< Server: AtlassianEdge
< Server-Timing: atl-edge;dur=13,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
< Strict-Transport-Security: max-age=63072000; preload
< Vary: Accept-Encoding
< X-Content-Type-Options: nosniff
< X-Xss-Protection: 1; mode=block
<
< 404 Not Found

== Step 3: PRM fetch matrix ==
> GET /.well-known/oauth-protected-resource/v1/mcp HTTP/1.1
> Host: mcp.atlassian.com
> Accept: application/json
>
> (empty body)
< HTTP/2.0 404 Not Found
< Atl-Request-Id: 28e8d58a-30c3-4119-a4fb-9e8faf8b0616
< Atl-Traceid: 28e8d58a30c34119a4fb9e8faf8b0616
< Cf-Ray: 9cbcb13db9c7f820-PDX
< Content-Length: 13
< Content-Type: text/plain; charset=UTF-8
< Date: Tue, 10 Feb 2026 15:38:14 GMT
< Ge-Edge-Trusted-Cloudflare-Proxy: bWNwLWNsb3VkZmxhcmUK
< Nel: {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}
< Report-To: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}
< Server: AtlassianEdge
< Server-Timing: atl-edge;dur=12,atl-edge-internal;dur=3,atl-edge-upstream;dur=11,atl-edge-pop;desc="aws-us-west-2"
< Strict-Transport-Security: max-age=63072000; preload
< Vary: Accept-Encoding
< X-Content-Type-Options: nosniff
< X-Xss-Protection: 1; mode=block
<
< 404 Not Found

┌────────────────────┤ LLM EXPLANATION ├─────────────────────┐
The primary failure in the AuthProbe scan—AUTH_REQUIRED_BUT_NOT_ADVERTISED—is valid and justified based on the MCP specification (MCP 2025-11-25) and related OAuth discovery standards (RFC 9728, RFC 8414). The key points supporting this conclusion are as follows:

---

Summary of Failure

• The server responds with 401 Unauthorized or 403 Forbidden status codes indicating authentication is required.
• The WWW-Authenticate header is present but missing the resource_metadata parameter essential for MCP/OAuth discovery.
• The OAuth Protected Resource Metadata (PRM) endpoints at the root (/.well-known/oauth-protected-resource) and the path-suffix (/.well-known/oauth-protected-resource/v1/mcp) return 404 Not Found instead of 200 OK.
• As a result, OAuth discovery is unavailable: no metadata about authorization servers, token endpoints, or dynamic client registration endpoints can be fetched.

---

Specification References and Requirements

1. RFC 9728 (OAuth Protected Resource Metadata Discovery)

   • Section 3 mandates that a protected resource must support discovery of metadata via a PRM endpoint:

     • For a resource with a URI path prefix (like /v1/mcp), the corresponding path-suffix PRM endpoint must exist. It should respond with 200 OK and a JSON document describing authorization servers and other OAuth details.
     • The root discovery endpoint (/.well-known/oauth-protected-resource) is also defined as an optional discovery starting point.

   • Section 4 defines that in case the resource requires authorization, the WWW-Authenticate response header must include a resource_metadata parameter with the URL of the PRM endpoint to enable clients to dynamically discover OAuth authorization servers and token endpoints.

2. MCP 2025-11-25

   • MCP uses OAuth 2.0 profiles and expects compatible discovery mechanisms as specified in RFC 9728 and RFC 8414 (OAuth Authorization Server Metadata).
   • As per MCP mode "best-effort," the server must advertise how to authorize via OAuth discovery metadata or clearly document any alternative authentication mechanisms.
   • The absence of resource_metadata in the WWW-Authenticate header violates MCP's requirement to signal OAuth-based auth on protected resources.

3. RFC 8414 (OAuth Authorization Server Metadata)

   • Specifies the metadata format and discovery process that MCP's PRM endpoints should utilize or extend.
   • Clients rely on this metadata to locate token endpoints, registration endpoints, and supported scopes.

4. RFC 3986 (URI Generic Syntax)

   • Ensures valid construction of PRM URLs and indicates that path-based discovery endpoints must be accessible at exact URI paths.

---

Correct Server Behavior per Spec

• On a 401 Unauthorized response:

  • The server must include a WWW-Authenticate header indicating the supported authentication schemes.
  • For OAuth-protected resources, this header must contain a resource_metadata="<PRM_URL>" parameter pointing to a valid PRM endpoint that returns OAuth metadata in JSON.

• The PRM endpoints must be implemented:

  • The root endpoint: /.well-known/oauth-protected-resource (optional but recommended).
  • The path-suffix endpoint: /.well-known/oauth-protected-resource/v1/mcp (mandatory for path-based protected resources).
  • These endpoints must respond with HTTP 200 OK and a JSON document with the correct OAuth metadata.

• If OAuth is not used, the server must advertise the actual required authentication scheme (e.g., AWS SigV4) clearly in the WWW-Authenticate header and/or in public documentation so clients know how to proceed.

---

Why the Failure Is Justified

• The absence of a valid PRM endpoint returning 200 OK JSON metadata (both root and path-suffix endpoints return 404 errors).
• The missing resource_metadata parameter in the WWW-Authenticate header means clients have no standardized way to discover authorization servers or token endpoints.
• This breaks the OAuth discovery flow described in MCP and RFC 9728, making automated client authorization infeasible.
• Consequently, AuthProbe rightly classifies this as a high severity, high confidence failure (AUTH_REQUIRED_BUT_NOT_ADVERTISED) because clients are told to authenticate but not how.

---

Recommendations to Fix the Failure

1. Implement the PRM path-suffix endpoint

   • Create the endpoint at /.well-known/oauth-protected-resource/v1/mcp that returns 200 OK with the JSON metadata describing authorization servers, token endpoints, and supported scopes, as defined in RFC 9728 and MCP 2025-11-25.

2. Add resource_metadata to WWW-Authenticate

   • Modify the 401 response to include a header like:

     WWW-Authenticate: Bearer resource_metadata="https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp", scope="..."
     

   • This explicitly advertises the OAuth discovery location to clients.

3. Alternatively, document and advertise an alternative authentication scheme

exit status 2