') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Atlassian MCP OAuth fails with "Incompatible authorization server (RFC 8414 §3.3)" on 1.0.79 — regression from 1.0.71 · Issue #4480 · github/copilot-cli · GitHub
Skip to content

Atlassian MCP OAuth fails with "Incompatible authorization server (RFC 8414 §3.3)" on 1.0.79 — regression from 1.0.71 #4480

Closed
Bug
Closed
Atlassian MCP OAuth fails with "Incompatible authorization server (RFC 8414 §3.3)" on 1.0.79 — regression from 1.0.71#4480
Bug
Assignees
mattdholloway
Labels
area:authenticationLogin, OAuth, device auth, token management, and keychain integrationarea:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry

Description

@jfrost-fabric
jfrost-fabric
opened on Aug 13, 2026

Summary

Since upgrading to 1.0.79 , connecting to the Atlassian remote MCP server ( https://mcp.atlassian.com/v1/mcp ) fails during OAuth discovery with:

MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect

The same server, same account, same on-disk state works on 1.0.71 . This appears to be a strict-issuer-validation regression, or at minimum a newly-enforced check that has no override for known-broken upstream metadata.

Environment

• OS: macOS (Darwin)
• Copilot CLI: 1.0.79 (broken) / 1.0.71 (working)
• MCP server: Jira/Atlassian → https://mcp.atlassian.com/v1/mcp 

Reproduction

  1. Start a fresh copilot session on 1.0.79 with the Atlassian MCP server configured.
  2. Attempt /mcp auth Jira/Atlassian (or let it auto-init).
  3. See the error above; server status stays at connecting .

 /mcp reload does not help. Wiping ~/.copilot/mcp-oauth-config/ does not help.

Root cause (Atlassian side)

Atlassian's metadata document violates RFC 8414 §3.3 — the advertised issuer doesn't match the discovery URL host:

$ curl -s https://mcp.atlassian.com/.well-known/oauth-authorization-server | jq .issuer
"https://cf.mcp.atlassian.com"

Discovery host is mcp.atlassian.com ; advertised issuer is cf.mcp.atlassian.com . Per §3.3, "the issuer value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata."

So Atlassian owns the underlying bug, but…

Why this is still a CLI issue

• 1.0.71 tolerates this and OAuth completes successfully (confirmed in an active session that re-authed today at 2026-08-13T16:35:35Z with a completely empty ~/.copilot/mcp-oauth-config/ ).
• 1.0.79 hard-fails with no override.

This is a regression that silently breaks every new session for a very widely used remote MCP server, with no user-facing way to opt into looser validation while Atlassian fixes their metadata.

Requested fix

Any one of:

  1. Relax the check to a warning until Atlassian corrects their document.
  2. Add an opt-in config flag per server (e.g. oauth: { allow_issuer_mismatch: true } or oauth: { trusted_issuers: [...] } ).
  3. A global --allow-oauth-issuer-mismatch / env var escape hatch.

Option 2 is safest — scoped per server, users still get the benefit of §3.3 everywhere else.

Evidence

Working session log (1.0.71) — cold OAuth, empty cache, success:

2026-08-13T16:35:34.741Z Server Jira/Atlassian requires authentication, initiating OAuth flow
2026-08-13T16:35:35.025Z OAuth authentication required for Jira/Atlassian
2026-08-13T16:35:35.064Z Successfully authenticated with Jira/Atlassian
2026-08-13T16:35:35.364Z MCP client for Jira/Atlassian connected, took 297ms

Failing session log (1.0.79) — same server, same host, same wiped cache:

MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect

Related

Also worth reporting to Atlassian so the underlying metadata gets fixed — happy to file that separately, but the CLI-side escape hatch is what unblocks users today

Metadata

Metadata

Assignees

Labels

area:authenticationLogin, OAuth, device auth, token management, and keychain integrationarea:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry

Type

Bug

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions