OAuth authentication fails at issuer validation

[NiceWaffel]

What version of Codex CLI is running?

0.143.0

What subscription do you have?

Free

Which model were you using?

No response

What platform is your computer?

No response

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

Trying to log in to an MCP Server using the Authorization Code flow fails with an error:

Error: failed to handle OAuth callback

Caused by:
    Authorization server response missing required issuer: expected https://my.mcp.server/issuer

This issue was introduced recently (works in 0.141.0 for example). I assume it is related to modelcontextprotocol/rust-sdk#896

What steps can reproduce the bug?

• Setup an MCP server with OAuth login
• Start logging in using codex mcp login my_mcp_server

What is the expected behavior?

Codex should handle the issuer contained in the iss parameter of the callback URL (see RFC 9207).

Additional information

No response

[fatalist]

Reproduced on 0.143.0 against a self-hosted MCP server (custom OAuth 2.1 AS, RFC 9207 compliant). I traced this end to end — it's a bug in Codex's callback handler, not in rmcp. rmcp already exposes the correct API; Codex calls the wrong variant and drops the iss before validation.

TL;DR

Our AS puts a valid iss in the authorization response (RFC 9207). Codex parses the loopback callback, discards iss, then calls the issuer-less handle_callback(code, state). rmcp meanwhile sets require_issuer = true from the AS metadata flag authorization_response_iss_parameter_supported, so it demands an iss it was never handed → AuthorizationServerMissingIssuer. It fails 100% of the time for any spec-compliant AS, even though a correct iss is on the wire.

Evidence — the iss really is in the callback

Captured the exact URL the browser delivers to Codex's loopback server:

http://127.0.0.1:PORT/callback/<callback_id>?code=<long-code>&state=<state>&iss=https%3A%2F%2Fapi.example.com

iss=https://api.example.com is present and equal to the discovery issuer. Codex throws it away before validation.

Root cause — codex-rs/rmcp-client/src/perform_oauth_login.rs

(commit 2c85975)

1. parse_oauth_callback() only captures code / state / error / error_description; the iss param falls into the catch-all and is dropped:

   match key {
       "code" => code = Some(decoded),
       "state" => state = Some(decoded),
       "error" => error = Some(decoded),
       "error_description" => error_description = Some(decoded),
       _ => {}   // <-- `iss` discarded here
   }

   OauthCallbackResult { code, state } has no field to carry it.

2. OauthLoginFlow::finish() then calls the issuer-less variant:

   self.oauth_state
       .handle_callback(&code, &csrf_state)   // issuer = None
       .await
       .context("failed to handle OAuth callback")?;   // <-- the error wrapper users see

Why rmcp then rejects it — crates/rmcp/src/transport/auth.rs

(paths/lines on main at time of writing)

• get_authorization_url() derives require_issuer straight from the AS metadata flag (≈ L1373):

  let require_issuer = metadata.additional_fields
      .get("authorization_response_iss_parameter_supported")
      .and_then(|v| v.as_bool())
      .unwrap_or(false);

• OAuthState::handle_callback → AuthorizationSession::handle_callback → handle_callback_with_issuer(code, csrf, None) → exchange_code_for_token_with_issuer(code, csrf, None).
• validate_authorization_response_issuer() (≈ L1528) with received_issuer = None and require_issuer = true returns AuthError::AuthorizationServerMissingIssuer (≈ L1544-1548).

So the RFC 9207 check rmcp added is correct; the value simply never reaches it because Codex didn't forward it.

The fix — rmcp already provides the right entry points

OAuthState exposes all three (≈ L3146-3179):

• handle_callback(code, csrf) — issuer-less (current call)
• handle_callback_with_issuer(code, csrf, Option<&str>)
• handle_callback_url(callback_url) — parses the full redirect URL via AuthorizationCallback::from_redirect_url, which does extract iss (≈ L2697-2707)

Option A (minimal): capture iss in parse_oauth_callback and thread it through:

// parse_oauth_callback:
"iss" => issuer = Some(decoded),
// OauthCallbackResult { code, state, issuer: Option<String> }

// finish():
self.oauth_state
    .handle_callback_with_issuer(&code, &csrf_state, issuer.as_deref())
    .await
    .context("failed to handle OAuth callback")?;

Option B: keep the raw callback URL and hand it to self.oauth_state.handle_callback_url(&full_url), letting rmcp parse code / state / iss itself.

---

This lines up with @NiceWaffel's guess about modelcontextprotocol/rust-sdk#896: that PR added issuer enforcement to rmcp. Codex's callback handler never forwarded iss, so the new enforcement surfaced the latent gap — hence "works in 0.141.0, broken in 0.143.0."

[tobernguyen]

Confirmed on 0.143.0 and 0.144.0 — the iss is present in the callback; Codex just doesn't forward it to the validator.

The check itself (in bundled rmcp from modelcontextprotocol/rust-sdk#896, crates/rmcp/src/transport/auth.rs) is correct: AuthorizationServerMissingIssuer fires only when require_issuer == true (derived from the AS advertising authorization_response_iss_parameter_supported: true) and received_issuer == None. And AuthorizationCallback::from_redirect_url parses iss from the query string just fine.

So the bug is in Codex's caller wiring: it reaches the validator with received_issuer = None even when the authorization server redirects back with a valid iss. Likely Codex is calling exchange_code_for_token (which passes None) instead of exchange_code_for_token_with_issuer, or isn't propagating the parsed AuthorizationCallback.issuer.

Minimal repro (no real IdP needed). A stub authorization server that advertises the flag and sends iss on the callback:

• AS metadata: { "issuer": "http://127.0.0.1:9700", "authorization_endpoint": ".../authorize", "token_endpoint": ".../token", "authorization_response_iss_parameter_supported": true }
• /authorize → 302 to the loopback redirect_uri with ?code=...&state=<echoed>&iss=http%3A%2F%2F127.0.0.1%3A9700

codex mcp add stub --url http://127.0.0.1:9700/mcp --oauth-client-id stub-client
codex mcp login stub
# Error: ... Authorization server response missing required issuer: expected http://127.0.0.1:9700

The redirect Codex receives demonstrably contains iss:

302 http://127.0.0.1:51137/callback/...?code=stub-auth-code&state=...&iss=http%3A%2F%2F127.0.0.1%3A9700

Dropping authorization_response_iss_parameter_supported from the AS metadata makes login succeed — confirming the callback's iss is never consumed and the check is gated purely on the advertised flag.

This breaks OAuth login against fully RFC 9207-compliant servers (e.g. any node-oidc-provider-based AS, which sends iss and advertises support by default). Downgrading isn't a workable fix since newer models require newer Codex.

[CaliLuke]

Independent reproduction on Codex CLI 0.144.1 (aarch64-apple-darwin, macOS 26.5.1) against a local Auto-K MCP server confirms the callback adapter drops a valid RFC 9207 issuer.

Authorization-server metadata returned:

{
  "issuer": "https://localhost:3000/api/auth",
  "authorization_response_iss_parameter_supported": true
}

The actual browser request to Codex's loopback listener contained the expected, percent-encoded iss (authorization code, state, and callback identifier redacted):

http://127.0.0.1:64626/callback/<redacted>?code=<redacted>&state=<redacted>&iss=https%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth

Codex nevertheless failed with:

Error: failed to handle OAuth callback

Caused by:
    Authorization server response missing required issuer: expected https://localhost:3000/api/auth

I reproduced the source-level diagnosis on the rust-v0.144.1 tag. In codex-rs/rmcp-client/src/perform_oauth_login.rs, OauthCallbackResult carries only code and state; parse_oauth_callback ignores iss; and finish calls the issuer-less handle_callback(&code, &csrf_state).

I then applied the minimal fix locally:

1. Add issuer: Option<String> to OauthCallbackResult.
2. Parse the iss query parameter (including percent decoding).
3. Call handle_callback_with_issuer(&code, &csrf_state, issuer.as_deref()).
4. Add a regression test using iss=https%3A%2F%2Fauth.example.com.

Fail-before evidence:

error[E0560]: struct `OauthCallbackResult` has no field named `issuer`

Pass-after evidence:

running 7 tests
...
test perform_oauth_login::tests::parse_oauth_callback_preserves_authorization_server_issuer ... ok
test result: ok. 7 passed; 0 failed

After building the patched 0.144.1 CLI, the unchanged authorization server and MCP stack completed the real flow:

Successfully logged in to MCP server 'autok_local'.

This isolates the failure to Codex's callback plumbing. The authorization server emits the correct iss, and rmcp correctly enforces it after the server advertises RFC 9207 support.

[EvanNotFound]

Reproduced with codex-cli 0.144.0-alpha.4, using the binary bundled with ChatGPT.app on macOS:

/Applications/ChatGPT.app/Contents/Resources/codex mcp login <server>

The authorization server is Better Auth 1.6.23 with issuer http://localhost:3000/api/auth. Dynamic registration, authorization, login, and consent complete successfully, but Codex reports:

Authorization server response missing required issuer:
expected http://localhost:3000/api/auth

This matches the callback-plumbing regression described above. A temporary compatibility workaround is to omit authorization_response_iss_parameter_supported from the MCP-discovered authorization-server metadata.

[microHoffman]

Same issue happening on 0.144.3 on Linux.