[Bug] OAuth metadata issuer mismatch for MCP OAuth endpoint

[pankaj pipada]

The Atlassian remote MCP OAuth endpoint appears to have an OAuth authorization server metadata issuer mismatch.

MCP URL used for Dynamic registration: `https://mcp.atlassian.com/v1/mcp/authv2`

The MCP protected resource metadata advertises the authorization server as:

`https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3`

but the authorization server metadata for that path returns:

`"issuer": "https://auth.atlassian.com"`

This causes strict OAuth/MCP clients to reject the flow during metadata discovery. For example, the official `modelcontextprotocol/go-sdk` fails with:

`failed to get authorization server metadata: metadata issuer "https://auth.atlassian.com" does not match issuer URL "https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3"`

RFC 8414 section 3.3 requires the `issuer` value in the metadata to match the issuer URL used for discovery:

https://datatracker.ietf.org/doc/html/rfc8414#section-3.3

## Reproduction

### 1. Call the MCP OAuth endpoint without authentication

Request:

```sh

curl -sS -D - -o /dev/null -X POST 'https://mcp.atlassian.com/v1/mcp/authv2' \

-H 'Content-Type: application/json' \

-H 'Accept: application/json, text/event-stream' \

-d '{

"jsonrpc": "2.0",

"id": 1,

"method": "initialize",

"params": {

"protocolVersion": "2025-06-18",

"capabilities": {},

"clientInfo": {

"name": "curl-debug",

"version": "0.0.1"

}

}

}'

```

Actual response:

```http

HTTP/2 401

date: Fri, 12 Jun 2026 10:14:48 GMT

content-type: application/json

content-length: 79

www-authenticate: Bearer resource_metadata="https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp/authv2", error="invalid_token", error_description="Missing or invalid access token"

cf-placement: remote-

server: AtlassianEdge

cf-ray: a0a81733c901c795-BOM

ge-edge-trusted-cloudflare-proxy: bWNwLWNsb3VkZmxhcmUK

x-content-type-options: nosniff

x-xss-protection: 1; mode=block

atl-traceid: d0e1e3c0a6a44bda956d594453c11572

atl-request-id: d0e1e3c0-a6a4-4bda-956d-594453c11572

strict-transport-security: max-age=63072000; preload

report-to: {"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}

nel: {"failure_fraction": 0.01, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}

server-timing: atl-edge;dur=419,atl-edge-internal;dur=2,atl-edge-upstream;dur=417,atl-edge-pop;desc="aws-ap-south-1"

```

The important header is:

```http

www-authenticate: Bearer resource_metadata="https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp/authv2", error="invalid_token", error_description="Missing or invalid access token"

```

### 2. Fetch the advertised protected resource metadata

Request:

```sh

curl -sS 'https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp/authv2' | jq

```

Actual response:

```json

{

"resource": "https://mcp.atlassian.com/v1/mcp/authv2",

"authorization_servers": [

"https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3"

],

"bearer_methods_supported": [

"header"

],

"scopes_supported": [

"read:me",

"read:account",

"offline_access",

"email",

"read:jira-work",

"write:jira-work",

"search:confluence",

"read:confluence-user",

"read:page:confluence",

"write:page:confluence",

"read:comment:confluence",

"write:comment:confluence",

"read:space:confluence",

"read:hierarchical-content:confluence",

"write:component:compass",

"read:component:compass",

"read:scorecard:compass",

"write:scorecard:compass",

"read:event:compass",

"read:metric:compass",

"read:all:twg",

"write:all:twg"

],

"resource_documentation": "https://www.atlassian.com/platform/remote-mcp-server"

}

```

This advertises the authorization server issuer URL as:

```txt

https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3

```

### 3. Fetch authorization server metadata for that advertised authorization server path

Request:

```sh

curl -s 'https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3/.well-known/oauth-authorization-server' | jq

```

Actual response:

```json

{

"issuer": "https://auth.atlassian.com",

"authorization_endpoint": "https://auth.atlassian.com/authorize",

"token_endpoint": "https://auth.atlassian.com/oauth/token",

"jwks_uri": "https://auth.atlassian.com/.well-known/jwks.json",

"registration_endpoint": "https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3/dcr/register",

"grant_types_supported": [

"authorization_code",

"client_credentials",

"refresh_token",

"urn:ietf:params:oauth:grant-type:token-revoke",

"urn:ietf:params:oauth:grant-type:jwt-bearer",

"urn:ietf:params:oauth:grant-type:token-exchange"

],

"revocation_endpoint": "https://auth.atlassian.com/oauth/revoke",

"code_challenge_methods_supported": [

"S256"

],

"response_types_supported": [

"code",

"token"

],

"pushed_authorization_request_endpoint": "https://auth.atlassian.com/oauth/par"

}

```

## Problem

The protected resource metadata advertises:

```json

"authorization_servers": [

"https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3"

]

```

But the authorization server metadata returns:

```json

"issuer": "https://auth.atlassian.com"

```

So the discovered authorization server URL and the metadata issuer do not match:

```txt

Advertised authorization server: https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3

Metadata issuer: https://auth.atlassian.com

```

This causes standards-compliant clients to fail before the browser authorization step.

The official MCP Go SDK reports:

```txt

calling "initialize": sending "initialize": rejected by transport: failed to get authorization server metadata: metadata issuer "https://auth.atlassian.com" does not match issuer URL "https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3"

```

## Expected behavior

The OAuth metadata chain should be internally consistent and value of issuer and metadata issuer should match exactly.

Either:

1. If the intended issuer is `https://auth.atlassian.com`, then the protected resource metadata should advertise:

```json

"authorization_servers": [

"https://auth.atlassian.com"

]

```

or:

2. If the intended issuer is `https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3`, then the authorization server metadata for that issuer should return:

```json

"issuer": "https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3"

```

## Actual behavior

The metadata mixes both issuer identifiers as mentioned above.

As a result, strict OAuth/MCP clients reject the flow during metadata discovery.

[pankaj pipada]

Any thing from anyone here? any one that can look at the bug?

[Dr Valeri Colon _Connect Centric_]

Welcome to the community @pankaj pipada Yes, this looks like a valid issue. Atlassian MCP supports OAuth 2.1/DCR, but RFC 8414 requires the metadata issuer to match the issuer URL exactly. Since strict clients reject the mismatch before consent, I’d raise this with Atlassian Support and include the curl outputs, trace ID, SDK error, and timestamp. 

https://support.atlassian.com/contact

[pankaj pipada]

thanks @Dr Valeri Colon _Connect Centric_ for your reply. When i go to the link and select rovo,it again takes me back to the same community page where I have posted this thing. I am a solo dev so dont really have a atlassian enterprise account. I am experimenting with MCPs via go sdk and found this issue. 

Any way to get in touch with support other than that? or may be we can tag someone here that can take this forward?

[Dr Valeri Colon _Connect Centric_]

@pankaj pipada @I notified Atlassian on your behalf and support engineer will be in touch within 2 days.

[Alin Oana]

@Dr Valeri Colon _Connect Centric_ What is the status on this issue? We are trying to set up an Atlassian MCP server configuration within LiteLLM and I think we are stumbling this exact issue.  Is there any workaround this problem we can use ?

[Dr Valeri Colon _Connect Centric_]

@Alin Oana I haven't seen a public update from Atlassian yet, so I believe this is still an open issue for clients that strictly validate the issuer per RFC 8414. Some OAuth clients allow issuer validation to be relaxed as a temporary workaround, but I wouldn't recommend that outside of local testing since issuer validation is an important security check. In the meantime, I'd encourage everyone affected to keep nudging Atlassian, as multiple reports help demonstrate the impact across different MCP clients.