OIDC issuer mismatch prevents authentication with Atlassian remote MCP server

[JAORMX]

Description

The Atlassian remote MCP server fails to authenticate due to an issuer mismatch in the OAuth/OIDC discovery process. The server's well-known endpoint returns a different issuer URL than what is expected based on the server's base URL.

Steps to Reproduce

1. Run thv run atlassian-remote
2. Observe authentication failure

Current Behavior

The authentication fails with the following error:

Error: failed to restart workload atlassian-remote: failed to authenticate to remote server: 
remote authentication failed: failed to discover registration endpoint: 
unable to discover OIDC endpoints at "https://mcp.atlassian.com/.well-known/openid-configuration" 
or "https://mcp.atlassian.com/.well-known/oauth-authorization-server": 
OIDC error: https://mcp.atlassian.com/.well-known/openid-configuration: HTTP 404, 
OAuth error: https://mcp.atlassian.com/.well-known/oauth-authorization-server: 
invalid metadata: issuer mismatch: expected https://mcp.atlassian.com, 
got https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev

Expected Behavior

The OIDC discovery should handle cases where the issuer URL differs from the base URL, allowing successful authentication with the Atlassian remote MCP server.

Additional Context

The OAuth authorization server metadata returns:

{
  "issuer": "https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev",
  "authorization_endpoint": "https://mcp.atlassian.com/v1/authorize",
  "token_endpoint": "https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev/v1/token",
  "registration_endpoint": "https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev/v1/register",
  // ... other fields
}

Note that the issuer field contains a different domain than the base URL (mcp.atlassian.com), which causes the validation to fail.

Proposed Solution

The OIDC discovery mechanism should be more flexible in handling issuer mismatches, possibly by:

1. Allowing configuration to skip issuer validation
2. Supporting an explicit issuer override in the configuration
3. Accepting the issuer from the well-known endpoint when it's from a trusted domain pattern

---

Originally reported by @ariel-miculas in #199 (comment)

[ariel-miculas]

Since we're on the Atlassian remote MCP topic, could you help me figure out what URL I should use to connect to the MCP server after setting up the proxy?

$ thv proxy --remote-auth --remote-auth-issuer="https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev" --target-uri=https://mcp.atlassian.com/ my-atlassian-remote
3:18PM  INFO    Using host port: 61830
3:18PM  INFO    Starting OAuth authentication flow for issuer: https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev
3:18PM  INFO    Successfully registered OAuth client dynamically - client_id: GdfpwDvg8egLVJi0
3:18PM  INFO    Using OAuth endpoints - authorize_url: https://mcp.atlassian.com/v1/authorize, token_url: https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev/v1/token
3:18PM  INFO    Opening browser to: https://mcp.atlassian.com/v1/authorize?client_id=GdfpwDvg8egLVJi0&code_challenge=UnMkTBbSAZd40NbMnkYw1GZ62GMxWmYB3k3VAp1tQy8&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A8666%2Fcallback&response_type=code&state=y9gXkRdf2SRgcZwlM258BQ
3:18PM  INFO    Starting OAuth callback server on port 8666
3:18PM  INFO    Waiting for OAuth callback...
3:19PM  INFO    OAuth flow completed successfully
3:19PM  INFO    OAuth authentication successful
3:19PM  INFO    Using OAuth config with introspection URL:
3:19PM  INFO    OIDC validation disabled, using local user authentication
3:19PM  INFO    Using local user authentication for user: amiculas
3:19PM  INFO    Setting up transparent proxy to forward from host port 61830 to https://mcp.atlassian.com/
3:19PM  INFO    Applied middleware 2
3:19PM  INFO    Applied middleware 1
3:19PM  INFO    Transparent proxy started for server my-atlassian-remote on port 61830 -> https://mcp.atlassian.com/
3:19PM  INFO    Press Ctrl+C to stop
3:19PM  INFO    Detected initialize method call for my-atlassian-remote


3:22PM  INFO    Detected initialize method call for my-atlassian-remote
3:32PM  INFO    Detected initialize method call for my-atlassian-remote

3:33PM  INFO    Detected initialize method call for my-atlassian-remote
3:33PM  INFO    Detected initialize method call for my-atlassian-remote

I tried

$ curl -X POST http://localhost:61830/mcp -H "Content-Type: application/json" -H "Accept: application/json,text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{"roots":{"listChanged":true},"sampling":{}},"clientInfo":{"name":"test-client","version":"1.0.0"}}}'
{"status":404,"message":"Not found"}

and

curl -X POST http://localhost:61830/v1/sse -H "Content-Type: application/json" -H "Accept: application/json,text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{"roots":{"listChanged":true},"sampling":{}},"clientInfo":{"name":"test-client","version":"1.0.0"}}}'
{"message":"Not found","status":404}

But they don't seem to work.
With the atlassian server at least I get an invalid access token error:

curl -X POST https://mcp.atlassian.com/v1/sse -H "Content-Type: application/json" -H "Accept: application/json,text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{"roots":{"listChanged":true},"sampling":{}},"clientInfo":{"name":"test-client","version":"1.0.0"}}}'
{"error":"invalid_token","error_description":"Missing or invalid access token"}

[amirejaz]

@ariel-miculas It’s more convenient to run the remote server i.e Atlassian remote MCP server using thv run with the issuer URL. This makes it easier to manage the remote server in the same way as a local one.

If you run thv list, you should be able to see the URL, and it will also be configured in the registered clients. Please let me know if you face any issue.

Here’s the official guide on running a remote MCP server:
https://docs.stacklok.com/toolhive/guides-cli/run-mcp-servers#run-a-remote-mcp-server

[ariel-miculas]

Thanks, @amirejaz
This seems to do the trick:

$ thv run https://mcp.atlassian.com/v1/sse --proxy-port 9000 --proxy-mode sse --transport sse --remote-auth --remote-auth-issuer https://atlassian-remote-mcp-production.atlassian-remote-mcp-server-production.workers.dev --name atlassian-mcp 

With this endpoint "atlassian-mcp-server": {"url":"http://localhost:9000/v1/sse"} configured in cursor.

[ariel-miculas]

Note: passing --enable-audit breaks the functionality of the mcp server, cursor can no longer retrieve the list of tools.

[amirejaz]

@ariel-miculas I'm glad that was helpful! The issuer mismatch validation is important to prevent CVEs, though in this case, the issuer seems legitimate. We'll add the issuer to the registry to avoid this mismatch issue going forward. I'll update you here once that's done, after that, it should be much more convenient to just run your original command: thv run atlassian-remote.