OAuth DCR client information is missing after Atlassian authorization, preventing refresh

[emmanuelchucks]

Summary

With Atlassian Rovo MCP's OAuth 2.1 endpoint, authorization succeeds and MCPorter stores both an eight-hour access token and a refresh token, but the resulting vault entry has no clientInfo. Once the access token expires, MCPorter cannot redeem the refresh token and falls back to sending the expired access token, producing 401 invalid_token and requiring another browser authorization.

I reproduced this independently on macOS and Linux with separate OAuth registrations.

Environment

• MCPorter: 0.12.3
• Node.js: 24.x
• Platforms: macOS and Linux
• Server: https://mcp.atlassian.com/v1/mcp/authv2
• Server config: HTTP transport with auth: "oauth"

Reproduction

1. Configure the Atlassian server:

   {
     "mcpServers": {
       "atlassian": {
         "baseUrl": "https://mcp.atlassian.com/v1/mcp/authv2",
         "auth": "oauth"
       }
     }
   }

2. Run mcporter auth atlassian --reset and complete the browser consent flow.

3. Confirm that the credential entry contains tokens.refresh_token and tokens.expires_at, but does not contain clientInfo. This can be checked without printing credentials:

   import fs from "node:fs";
   import os from "node:os";
   import path from "node:path";
   
   const vault = JSON.parse(
     fs.readFileSync(path.join(os.homedir(), ".mcporter", "credentials.json"), "utf8"),
   );
   const entry = Object.values(vault.entries).find(
     (candidate) => candidate.serverName === "atlassian",
   );
   console.log({
     hasRefreshToken: Boolean(entry?.tokens?.refresh_token),
     hasClientInfo: Boolean(entry?.clientInfo?.client_id),
   });

   Observed immediately after successful authorization:

   { hasRefreshToken: true, hasClientInfo: false }
   

4. After the access token's eight-hour lifetime, run:

   MCPORTER_LOG_LEVEL=debug \
     mcporter list atlassian --status --json --no-oauth

   The relevant output is:

   Cached OAuth token for 'atlassian' is expired, but no client information is available.
   Using cached OAuth access token for 'atlassian' (non-interactive).
   

   The request then fails with HTTP 401 and {"error":"invalid_token"}.

Expected behavior

The dynamic client registration used during authorization should remain available with the token set so MCPorter can silently redeem the refresh token after access-token expiry.

Additional evidence

• Atlassian advertises offline_access and refresh_token; the grant includes offline_access, and a refresh token is present.
• The authorization request contains a dynamically registered client_id.
• The issued access-token JWT contains the same client_id, confirming the grant is bound to that registration.
• The two reproductions used different client IDs, so this was not one host invalidating another host's refresh chain.

As a local diagnostic, I restored minimal client information from each host's own JWT claim:

{
  "client_id": "<the token's client_id claim>",
  "token_endpoint_auth_method": "none"
}

Without reauthorizing, the already-expired Linux credential then refreshed successfully:

Refreshed cached OAuth access token for 'atlassian' (non-interactive).

A subsequent server status check and authenticated read both passed. This suggests the refresh-token and silent-refresh paths are healthy once the registration information is available.

Related issues checked

• list reports auth required on expired access_token even when refresh_token is valid #166 covers silent refresh when usable client information is already available.
• OAuth: hardcoded scope: 'mcp:tools' ignores resource server's advertised scopes, so no refresh token is issued (sessions die at access-token TTL) #196 covers obtaining a refresh token via metadata-derived offline_access.
• Using with atlassian MCP ? #26 confirms general Atlassian MCP connectivity.

This appears distinct: the refresh token exists, but the dynamic client information needed to use it is absent after successful authorization.

No access tokens, refresh tokens, client IDs, authorization codes, states, or PKCE values are included here.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 3, 2026, 10:55 AM ET / 14:55 UTC.

Summary
Keep this issue open. The updated isolated-state reproduction on current main establishes that Atlassian OAuth discovery now fails before authorization, dynamic client registration, or refresh can occur; resolving it safely requires a maintainer decision on issuer-equivalence boundaries rather than a speculative DCR-persistence patch.

Reproducibility: yes. The reporter supplied an isolated-state current-main trace that fails deterministically during OAuth discovery when Atlassian's selected authorization-server URL has an opaque path but the returned metadata declares an origin-only issuer; that revision is an ancestor of current main with no relevant OAuth changes afterward.

Maintainer decision needed

Question	Recommendation
May MCPorter treat an Atlassian authorization-server URL with a provider-specific opaque path as equivalent to metadata declaring the origin-only issuer, and if so what exact constraints must prevent cross-issuer credential reuse?	Approve a narrow Atlassian compatibility rule: Permit only the documented Atlassian URL-to-issuer relationship, preserve strict matching for all other authorization servers, and require positive and cross-issuer rejection tests.

Why: The current strict comparison intentionally protects persisted client registrations and refresh tokens. Source and tests establish the safety boundary, but the redacted provider path and acceptable equivalence rule require maintainer security and compatibility judgment.

Next step
A maintainer must define the permitted issuer-equivalence boundary before a focused fix can be safely assigned; automation should not guess at credential-binding policy.

Security
Needs attention: Any repair changes an issuer-to-credential binding boundary, so it needs a narrowly defined compatibility rule and regression proof before implementation.

Review details

Best possible solution:

Approve and implement only a narrowly defined, documented issuer-compatibility rule for the observed Atlassian metadata relationship, with regression coverage proving both legitimate authorization and rejection of unrelated issuers.

Do we have a high-confidence way to reproduce the issue?

Yes. The reporter supplied an isolated-state current-main trace that fails deterministically during OAuth discovery when Atlassian's selected authorization-server URL has an opaque path but the returned metadata declares an origin-only issuer; that revision is an ancestor of current main with no relevant OAuth changes afterward.

Is this the best way to solve the issue?

No, the original dynamic-client-persistence diagnosis is no longer the narrowest current fix because discovery aborts before DCR can run. A focused issuer-compatibility repair is plausible only after maintainers define the allowed security boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Broadening issuer matching could cause MCPorter to reuse a dynamic client registration or refresh token across distinct authorization servers, weakening the credential-binding protection covered by current tests.

Codex review notes: model internal, reasoning high; reviewed against f0bd0d828f11.

Label changes

Label changes:

• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: Current main blocks a real remote-server OAuth authorization flow before users can obtain working credentials.
• impact:auth-provider: The directly observed failure is authorization-server metadata issuer validation in the OAuth provider path.
• impact:session-state: The original report and current authorization failure prevent establishing the durable credential state required for later refresh.

Evidence reviewed

Security concerns:

• [high] Preserve issuer-bound credential isolation — src/oauth.ts:514
  The current comparison prevents stored dynamic client registrations and refresh tokens from being reused after an issuer change; an unbounded path/origin equivalence exception could transmit credentials to the wrong authorization server.
  Confidence: 0.94

What I checked:

• Current source enforces strict issuer matching: Persisted dynamic client registrations are discarded unless their issuer exactly matches the issuer supplied by the SDK, apart from a trailing slash; this is the local credential-binding boundary relevant to any compatibility change. (src/oauth.ts:282, f0bd0d828f11)
• Current tests deliberately protect issuer separation: The OAuth session regression test clears client and token records when their issuer differs, while the persistence test verifies that a mismatched issuer does not transmit the refresh token. (tests/oauth-session.test.ts:198, f0bd0d828f11)
• Reporter reproduction remains current-main evidence: The reporter ran an isolated authorization at 96a0989 and observed RFC 8414 issuer validation fail before an authorization URL, callback, DCR result, or tokens existed. That revision is an ancestor of current main, and no OAuth implementation, SDK dependency, or OAuth test file changed between it and f0bd0d8. (src/oauth.ts:514, f0bd0d828f11)
• OAuth issuer binding has recent feature-history ownership: Recent local history identifies the issuer-binding change as "fix(oauth): bind silent refresh to issuer" by Peter Steinberger, followed by adjacent OAuth hardening work; this supports routing the security-boundary decision to the current OAuth-area contributor. (src/oauth-token-refresh.ts:79, 5a6a012e1706)
• Main-only state, not a shipped fix: Current main declares version 0.13.0, while no local release tag contains either the reporter revision or current main; the latest supplied release is v0.12.4. This issue is not fixed on main or in a release. (package.json:3, f0bd0d828f11)

Likely related people:

• steipete: Peter Steinberger authored the recent issuer-binding and adjacent OAuth-hardening commits, and steipete's maintainer comments identified the strict comparison as the decision point. (role: recent OAuth-area contributor; confidence: high; commits: 5a6a012e1706, dac92c30c876; files: src/oauth.ts, src/oauth-token-refresh.ts, tests/oauth-session.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.