Atlassian MCP OAuth fails: unauthorized_client: redirect_uri is not registered (v2 endpoint)

[bart-rijnders]

Title

Atlassian MCP OAuth fails: unauthorized_client: redirect_uri is not registered (v2 endpoint)

Affected version

1.0.86 (also observed on prior builds per related issues #4490, #2536)

Environment

• OS: macOS
• MCP server config (~/.copilot/mcp-config.json):

  {
    "mcpServers": {
      "atlassian": {
        "type": "http",
        "url": "https://mcp.atlassian.com/v2/mcp",
        "tools": ["*"]
      }
    }
  }

Description

When authenticating to the Atlassian MCP server (https://mcp.atlassian.com/v2/mcp), the OAuth flow fails on Atlassian's side with:

https://id.atlassian.com/error?error=unauthorized_client&error_description=redirect_uri%20is%20not%20registered%20for%20client:%20http://127.0.0.1:<random-port>/

The client_id used appears to differ from — or its declared metadata does not include — the dynamic loopback redirect_uri (http://127.0.0.1:<random-port>/) that Copilot CLI generates for each auth attempt.

By contrast, VS Code's Atlassian/Rovo Dev MCP integration succeeds using a Client ID Metadata Document (CIMD) approach: its client_id is a URL (https://vscode.dev/oauth/client-metadata.json) whose fetched JSON document lists VS Code's trusted redirect URIs. Atlassian's authorization server fetches this metadata document to validate the redirect_uri instead of requiring prior Dynamic Client Registration (DCR).

Local log excerpts (~/.copilot/logs/process-*.log) confirm the flow:

[ERROR] [rust:rmcp::transport::worker] worker quit with fatal: Transport channel closed, when Client(OAuthChallenge { www_authenticate_header: "...https://mcp.atlassian.com/.well-known/oauth-protected-resource/v2/mcp...", response: McpOAuthHttpResponse { status_code: 401, ... } })
[ERROR] Connecting to atlassian...
[ERROR] Opening browser for atlassian authentication...

No client-registration record is persisted locally (~/.copilot/mcp-oauth-config/ only contains a PKCE .verifier file), suggesting Copilot CLI attempts a fresh DCR (or static client_id) each time rather than caching/reusing a CIMD-style registration — and whatever it sends doesn't match what Atlassian's server expects.

Steps to reproduce

1. Configure Atlassian HTTP MCP server pointing to https://mcp.atlassian.com/v2/mcp.
2. Run /mcp → select atlassian → attempt to authenticate.
3. Browser opens https://auth.atlassian.com/authorize?...&redirect_uri=http://127.0.0.1:<random-port>/....
4. Atlassian immediately redirects to an error page: unauthorized_client: redirect_uri is not registered for client: http://127.0.0.1:<random-port>/.

Expected behavior

OAuth flow completes successfully, matching VS Code's behavior against the same Atlassian MCP endpoint.

Suggested fix

• Adopt the same Client ID Metadata Document (CIMD) pattern VS Code uses: host/declare a client-metadata.json for Copilot CLI listing its expected loopback redirect URI pattern, and use that document's URL as client_id.
• Alternatively, verify whether Atlassian's /register (DCR) endpoint is being called at all before /authorize, and confirm the registered redirect_uris match the one sent in the subsequent authorize request.

Related issues

• Atlassian MCP OAuth authentication broken in 1.0.80 (RFC 8414 §3.3 regression) #4490 (RFC 8414 issuer mismatch, v1.0.80)
• Atlassian MCP needs authorization on every invocation of the copilot cli #2536 (re-auth required on every launch)

[shawjef3]

Additional data from my copilot:

Comment for #4901

Additional findings that refine the root cause — and correct the suggested fix.

The CLI already uses CIMD; the bug is that it ignores its own metadata document

The issue suggests adopting VS Code's Client ID Metadata Document (CIMD) pattern, but the CLI already uses CIMD. A captured authorize URL shows:

client_id = https://github.com/copilot/cli/client-metadata.json

That document currently declares exactly one allowed redirect URI:

{
  "client_id": "https://github.com/copilot/cli/client-metadata.json",
  "client_name": "GitHub Copilot CLI",
  "application_type": "native",
  "token_endpoint_auth_method": "none",
  "redirect_uris": ["http://127.0.0.1:33418/"]
}

(Fetched from https://github.com/copilot/cli/client-metadata.json.)

However, the CLI binds its local OAuth callback to a random loopback port on each attempt and sends that as the redirect_uri. Example from a captured authorize URL:

redirect_uri = http://127.0.0.1:61876/

Atlassian fetches the metadata document, sees that only http://127.0.0.1:33418/ is registered, and rejects any other port with:

unauthorized_client: redirect_uri is not registered for client: http://127.0.0.1:<random-port>/

Root cause

The mismatch is between the CLI's declared redirect URI (fixed port 33418 in client-metadata.json) and the port it actually binds/sends (random). Atlassian's CIMD validation requires an exact match, so every attempt fails.

Correction to the suggested fix

CIMD is already adopted — the client_id is the metadata URL. The fix is one of:

1. Bind the OAuth callback to the fixed port 33418 declared in the metadata document (preferred; matches what the CLI already advertises), or
2. List the actual loopback port range the CLI uses in client-metadata.json's redirect_uris (loopback clients per RFC 8252 are allowed to vary the port, but the CIMD document must then enumerate/allow them — Atlassian appears to require exact matches).

Additional data point

On an affected macOS machine, port 33418 was verified free and bindable, yet the CLI still fell back to a random port — so the fallback is not caused by port 33418 being occupied.

Captured evidence

• Authorize URL: client_id=https://github.com/copilot/cli/client-metadata.json and redirect_uri=http://127.0.0.1:61876/ (also seen: 60947, 61887).
• Metadata document redirect_uris: ["http://127.0.0.1:33418/"].
• ~/.copilot/mcp-oauth-config/ contains only a PKCE .verifier, consistent with the report.
• Version: 1.0.86, macOS.