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

Activity

  1. github-actions
    added
    triage
    on Aug 13, 2026
  2. copilot-cli-release-app
    added the
    Bug
    issue type on Aug 14, 2026
  3. copilot-cli-release-app
    added
    area:authenticationLogin, OAuth, device auth, token management, and keychain integration
    area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry
    and removed
    triage
    on Aug 14, 2026

  4. pigovsky commented on Aug 14, 2026

    @pigovsky
    pigovsky
    on Aug 14, 2026

    please fix it

  5. IrynaKulakova
    assigned
    mattdholloway
    on Aug 14, 2026
  6. mattdholloway
    closed this as completedon Aug 14, 2026

  7. swestcott commented on Aug 14, 2026

    @swestcott
    swestcott
    on Aug 14, 2026

    We found that Atlassian changed their endpoint from https://mcp.atlassian.com/v1/mcp to https://mcp.atlassian.com/v1/mcp/authv2 back in ~May according to Wayback Machine. Configuring Copilot 1.0.79 to use this updated URL has resolved the issue for us.

  8. jg-par commented on Aug 14, 2026

    @jg-par
    jg-par
    on Aug 14, 2026

    We found that Atlassian changed their endpoint from https://mcp.atlassian.com/v1/mcp to https://mcp.atlassian.com/v1/mcp/authv2 back in ~May according to Wayback Machine. Configuring Copilot 1.0.79 to use this updated URL has resolved the issue for us.

    thank you for saving my life

  9. mattdholloway
    reopened this on Aug 17, 2026

  11. mohamedkamal9918 commented on Aug 17, 2026

    @mohamedkamal9918
    mohamedkamal9918
    on Aug 17, 2026

    Envoyé de mon iPhone

    Le 17 août 2026 à 13:26, Matt Holloway @.***> a écrit :

    

    Reopened #4480#4480.

    —
    Reply to this email directly, view it on GitHub#4480, or unsubscribehttps://github.com/notifications/unsubscribe-auth/CIQKIGUBXQRNW6NLAOMWCY35KM56BAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJYGYYDMNRUHNEXG43VMU5TKMJUGUZDMMZUHAZKC5QC.
    Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOShttps://github.com/notifications/mobile/ios/CIQKIGTUCVR6VMXMUIBX3MD5KM56BA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTEOJVG4ZDEMBYGAYDHJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG and Androidhttps://github.com/notifications/mobile/android/CIQKIGUBCEUPCBQU3VPNJ6L5KM56BA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTEOJVG4ZDEMBYGAYDHJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA. Download it today!
    You are receiving this because you are subscribed to this thread.Message ID: @.***>

    Overview of the upgrade process

    Learn the recommendations and requirements for upgrading GitHub Enterprise Server, so you can plan and test your upgrade strategy.

    GitHub Enterprise Server is constantly improving, with new functionality and bug fixes introduced through feature and patch releases. You are responsible for upgrades to your instance. See About upgrades to new releases.

    To upgrade an instance, you must:

    1. Plan your upgrade strategy by choosing your upgrade version and the appropriate upgrade package, and scheduling a maintenance window.
    2. Communicate the upgrade before and during the upgrade process.
    3. Prepare your backup strategy by creating a backup and taking a virtual machine snapshot.
    4. Install the upgrade package using the appropriate package and method.
    5. Complete post-upgrade tasks.

    The process you must follow to apply an upgrade package depends on how many nodes are in your deployment topology. This article provides general information for upgrading instances in a standalone or high availability configuration only.

    Planning your upgrade strategy

    Plan your upgrade

    • Review the release notes and documented known issues before performing an upgrade. See Release notes and Known issues with upgrades to your instance.
    • Review Upgrade requirements to ensure you understand the requirements and recommendations for upgrading.
    • Check that your GitHub Enterprise Server instance's data disk is at least 15% free. GitHub recommends ensuring there is additional free storage on the disk. In some rare cases, for customers with large data volumes, this threshold may differ. See Increasing storage capacity.
    • Check that you have sufficient hardware resources for GitHub Enterprise Server. When upgrading, pre-flight checks evaluate if the minimum requirements for system hardware resources, such as memory, CPU cores, and user and root disk storage, are available to your instance. If pre-flight checks determine there are insufficient resources, or otherwise fail, you are notified and the upgrade is aborted.
    • Ensure you have a copy of all custom firewall rules for your GitHub Enterprise Server instance, as customized rules will not persist post-upgrade. You must reapply any custom rules following the upgrade. See Configuring built-in firewall rules.
    • For instances in a high availability configuration, check that the status of replication reports OK before upgrading. See Monitoring a high-availability configuration.
    • Consider configuring the IP exception list for maintenance mode, so you can temporarily limit access to your GitHub Enterprise Server instance to validate your server health after an upgrade. See Enabling and scheduling maintenance mode.

    Choose your upgrade version and package

    • Determine an upgrade strategy and choose a version to upgrade to.
      • You can upgrade a GitHub Enterprise Server instance to a new patch release or to a new feature release.
      • Refer to the Upgrade assistant to find the upgrade path from your current release version, to a new patch or feature release version.
    • Choose an upgrade package (hotpatch or upgrade package).
      • To upgrade to a patch release, you can use a hotpatch or an upgrade package. To upgrade to a feature release, you must use an upgrade package.
      • If you use an upgrade package, schedule a maintenance window for GitHub Enterprise Server end users. If you are using a hotpatch, maintenance mode is not required.
      • If you have enabled automatic update checks, site administrators will be notified that an upgrade package has been downloaded and is available. See Enabling automatic update checks.
      • Release candidate builds are intended solely for use in a test environment. Do not install a release candidate build in a production environment. Do not upgrade from the release candidate to later versions, including generally available releases.

    Consider if other application updates are required

    Check if you need to upgrade the following applications:

    • GitHub Actions runners must be updated if your GitHub Enterprise Server instance uses ephemeral self-hosted runners for GitHub Actions and automatic updates are disabled. Upgrade runners to the minimum version of application required by your upgraded instance, before performing your upgrade. To find the minimum required version for your release, see GitHub Enterprise Server releases.

    Plan a maintenance window

    • Depending on your upgrade strategy, significant downtime may be required.
    • The best way to determine the expected duration of downtime is to test your upgrade in a staging environment first. See Setting up a staging instance.
    • The maintenance window for your upgrade depends on the type of upgrade you perform.

      • Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time.

        [!NOTE]
        Hotpatches require a configuration run, which can cause a brief period of errors or unresponsiveness for some or all services on your GitHub Enterprise Server instance. You are not required to enable maintenance mode during installation of a hotpatch, but doing so will guarantee that users see a maintenance page instead of errors or timeouts. See Enabling and scheduling maintenance mode.

      • Patch releases using an upgrade package typically require less than five minutes of downtime.

      • Upgrading to a new feature release that includes data migrations may cause a few hours of downtime, depending on storage performance and the amount of data that is migrated. During this time none of your users will be able to use the enterprise. You may notice that upgrades to a new feature release take less time. This is because selective database transitions will now run concurrently, with the number of concurrent workers defaulting to the number of CPU cores, up to a maximum of 16.

    Communicating your upgrade

    Preparing your backup strategy

    Create a backup snapshot

    Ensure you have a recent, successful backup snapshot of your instance's primary node before you start the upgrade process. See About the backup service for GitHub Enterprise Server and the README in the GitHub Enterprise Server Backup Utilities project documentation.

    Create a VM snapshot

    If you're upgrading to a new feature release, a virtual machine (VM) snapshot is required. If you're upgrading to a patch release, you can attach the existing data disk.

    Create a virtual machine (VM) snapshot of your instance's primary node immediately before upgrading, and only when maintenance mode has been enabled or the instance has been powered down. See Taking a snapshot.

    Installing an upgrade package

    Review the considerations for upgrades, and complete any preparation steps as described above, before you start installing an upgrade package.

    The instructions for upgrading your GitHub Enterprise Server instance differ depending on the type of upgrade you're performing and the number of nodes your instance has.

    Completing post-upgrade tasks

    • Check the status of background jobs, and review the upgrade log for errors.
    • Check basic GitHub Enterprise Server functionality. For example, ensure you can sign in via the user interface, and verify that several of your organizations, repositories and issues can be reached as expected. It's also a good idea to manually run several Git fetches, clones, and pushes using SSH and/or HTTPS, and check that API requests and webhook deliveries complete successfully.
    • Reapply any custom firewall rules. See Configuring built-in firewall rules.
    • Delete any VM snapshots taken prior to upgrading. See Taking a snapshot.
    • Disable maintenance mode, and update any pre-upgrade communications such as announcement banners. See Customizing user messages for your enterprise and Enabling and scheduling maintenance mode.
    • Monitor all queued background jobs on your instance to ensure they complete successfully. See Command-line utilities.

  12. pskoett commented on Aug 19, 2026

    @pskoett
    pskoett
    on Aug 19, 2026

    Same RFC 8414 §3.3 failure on SAP LeanIX MCP (Copilot 1.0.80). Unlike Atlassian, there is no working authv2 URL.

    Official / generic endpoint:

    • MCP: https://mcp.leanix.net/services/mcp-server/v1/mcp
    • advertised authorization_servers: https://mcp.leanix.net/services/mcp-server/v1
    • AS metadata issuer: https://mcp.leanix.net

  13. IrynaKulakova commented on Aug 28, 2026

    @IrynaKulakova
    IrynaKulakova
    on Aug 28, 2026

    Fix is available in the last update.

  14. IrynaKulakova
    closed this as completedon Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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