Create
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Community resources
Community resources
Community resources
[Bug] OAuth metadata issuer mismatch for MCP OAuth endpoint
pankaj pipada
June 12, 2026 edited
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:
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:
## Reproduction
### 1. Call the MCP OAuth endpoint without authentication
Request:
```sh
-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
```
Actual response:
```json
{
"authorization_servers": [
],
"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"
],
}
```
This advertises the authorization server issuer URL as:
```txt
```
### 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
{
"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"
],
"code_challenge_methods_supported": [
"S256"
],
"response_types_supported": [
"code",
"token"
],
}
```
## Problem
The protected resource metadata advertises:
```json
"authorization_servers": [
]
```
But the authorization server metadata returns:
```json
```
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": [
]
```
or:
2. If the intended issuer is `https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3`, then the authorization server metadata for that issuer should return:
```json
```
## Actual behavior
The metadata mixes both issuer identifiers as mentioned above.
As a result, strict OAuth/MCP clients reject the flow during metadata discovery.
0 answers
Copyright © 2026 Atlassian