codex mcp login omits OAuth resource indicator from authorize request, causing wrong token audience

[bluedog13]

Summary

When running:

codex mcp login example-mcp --scopes myscope,offline_access

Codex CLI opens an OAuth authorize URL that includes the requested scopes, but omits the protected resource indicator for the target MCP server.

Because resource is missing, the authorization server can mint a token for a default audience instead of the MCP server being logged into.

Environment

• Codex CLI: codex-cli 0.111.0
• OS: macOS
• Arch: arm64

Reproduction

1. Configure an MCP server whose protected resource is something like:

   https://resource.example.com/mcp
   

2. Run:

   codex mcp login example-mcp --scopes myscope,offline_access

3. Observe the authorize URL printed by Codex CLI.

Actual behavior

Codex CLI prints an authorize URL shaped like:

https://auth.example.com/connect/authorize?response_type=code&client_id=...&state=...&code_challenge=...&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3ANNNNN%2Fcallback&scope=myscope+offline_access

The URL is missing:

&resource=https%3A%2F%2Fresource.example.com%2Fmcp

Login then reports success, but the resulting token audience is for a different resource than the MCP server being logged into.

Expected behavior

Codex CLI should include the discovered MCP protected resource in the OAuth request, for example:

...&scope=myscope+offline_access&resource=https%3A%2F%2Fresource.example.com%2Fmcp

The token request should also be checked to ensure the same resource value is carried through consistently.

Impact

This makes codex mcp login appear successful while producing a token for the wrong audience/resource, which then breaks authentication against the intended MCP server.

Notes

This appears to be an MCP OAuth flow issue in Codex CLI rather than a DCR issue.

The target MCP server advertises its protected resource via OAuth protected resource metadata, and the CLI appears to be honoring scopes but not the discovered resource indicator.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• omits OAuth indicator from authorize request, causing wrong token audience #13890
• Codex mcp login fails with OAuth providers that require resource (eg. MarketingCloud MCP) #12589
• MCP OAuth login cannot pass RFC 8707 resource parameter #12762

Powered by Codex Action

[bluedog13]

Fix Available

I have a fix for this issue on my fork: bluedog13/codex@fix-mcp-oauth-resource-binding

Unable to open a PR directly (repo restricts to collaborators), but the branch is ready to merge.

Root Cause

rmcp 0.15.0 did not add the RFC 8707 resource parameter to the authorization URL or token exchange. The Codex wrapper only appended it when explicitly configured via oauth_resource, leaving the default case without any resource binding — causing tokens to be minted for the wrong audience.

Changes (6 files, 1 commit)

• Bump rmcp 0.15.0 → 0.16.0 — natively adds resource=server_url to both the authorization URL and token-exchange request (RFC 8707)
• Bump reqwest to 0.13 in rmcp-client only — required by rmcp 0.16
• Align StreamableHttpClient::post_message with new extra_headers param added in rmcp 0.16
• Add replace_query_param helper for explicit oauth_resource config overrides
• Add integration tests for default and override resource flows

Verification

• cargo check --workspace — passes
• cargo test -p codex-rmcp-client — all 33 tests pass
• New test oauth_login_includes_server_url_resource_by_default verifies resource=server_url in both auth URL and token request
• New test oauth_login_uses_configured_oauth_resource_when_provided verifies override in auth URL

Compare: main...bluedog13:codex:fix-mcp-oauth-resource-binding

[razashariff]

The audience mismatch here is a symptom of a broader gap — MCP authentication is entirely dependent on OAuth, which breaks in multiple ways (wrong audience, expired tokens, missing DCR support, remote environments).

MCPS (MCP Secure) provides a complementary per-message signing layer that works independently of OAuth state. Every MCP message carries an ECDSA P-256 signature binding the agent identity (passport_id), a unique nonce, timestamp, and SHA-256 hash of the full JSON-RPC body. Even if the OAuth token is scoped to the wrong audience, the MCPS signature cryptographically proves which agent made the request and that the message was not tampered with in transit.

Published as an IETF Internet-Draft and available on npm as mcp-secure (zero dependencies).

[SproutSeeds]

The default authorize path still only gets resource through append_query_param(..., "resource", oauth_resource) in codex-rs/rmcp-client/src/perform_oauth_login.rs.

• Codex sends resource only when oauth_resource is configured explicitly
• when the protected resource should come from MCP / OAuth metadata, the default authorize request goes out without it
• the token exchange in rmcp 0.15.0 also runs without adding resource

The authorize request and token exchange are both missing default resource binding.
This is not a dynamic client registration issue.
Carry the discovered protected resource by default while still letting explicit oauth_resource override it on both requests.

[bluedog13]

Thanks for the analysis — you're describing the exact root cause my fix addresses. The rmcp 0.15.0 → 0.16.0 bump natively adds resource=server_url to both the authorization URL and the token exchange request by default (RFC 8707), so explicit oauth_resource configuration is no longer required for the default case. The explicit oauth_resource config still works as an override when needed.

You can see the full diff here: main...bluedog13:codex:fix-mcp-oauth-resource-binding