Researched guidance: How should MCP OAuth redirect mismatches be diagnosed without weakening validation?

Summary

Diagnose MCP OAuth redirect mismatches as precise registration/request/callback/token consistency failures; repair the canonical URI rather than weakening validation.

Candidate action

Capture sanitized redirect_uri values at registration, authorization request, callback receipt, and token exchange; compare exact strings. Keep scheme, host, path, and query identical. The only narrow exception is a native-app loopback HTTP redirect where the port may vary. Do not use wildcards, prefix matching, or broad URL normalization; align registration, request generation, callback binding, and token exchange, then verify state, issuer, and PKCE before code redemption.

Applicability

• HTTP-based MCP OAuth authorization-code flows using pre-registration, Client ID Metadata Documents, or Dynamic Client Registration.
• Native desktop clients using loopback redirects under RFC 8252/RFC 9700.
• MCP deployments following the 2026-07-28 authorization and security-considerations pages.

Procedure

• Classify HTTP MCP OAuth versus STDIO, client type, authorization-server issuer, registration mechanism, and MCP version; record only sanitized URI components and error text.
• Compare registered redirect_uris with the authorization-request redirect_uri using simple string comparison; inspect scheme, host, port, path, query, slash, encoding, and case without silent normalization.
• Apply the native loopback exception only for a true native client using http://127.0.0.1:{port}/path or http://[::1]:{port}/path: only port may vary; do not generalize to arbitrary HTTP, hosts, wildcards, or paths.
• If redirect_uri was in the authorization request, send the identical value in the token request and verify authorization-code binding to it.
• For dynamic registration or Client ID Metadata Documents, verify the client_id and the redirect_uris actually stored or fetched; check for stale or environment-specific registrations.
• At callback, bind the response to the pending transaction: verify state when used, compare recorded issuer/iss exactly for multi-server flows, and require PKCE with S256 where capable before sending the code.
• Use one canonical URI per environment; test the same sanitized value through registration, authorization, callback, and token exchange. Keep callback handlers free of open redirects and loopback listeners short-lived and loopback-only.

Key findings

• MCP requires registered redirect URIs, exact validation, HTTPS or localhost redirects, and state verification guidance; MCP authorization records issuer state for response validation. (S1, S2)
• RFC 9700 requires exact matching except the native localhost port exception, rejects pattern matching/open redirectors, and requires redirect_uri consistency at token exchange. (S3)
• RFC 6749 requires complete registration where possible, simple string comparison for full URIs, no redirect to invalid URIs, and identical redirect_uri at token exchange when initially supplied. (S4)
• RFC 8252 defines native loopback redirects with 127.0.0.1 or [::1], varying port only for that loopback case, plus PKCE and callback protections. (S5)

Comparison

Known limitations

• The MCP 2026-07-28 security page says redirects must be localhost or HTTPS and exact, but does not itself spell out a dynamic-port exception; RFC 8252 and RFC 9700 explicitly define native loopback-IP HTTP and variable-port handling. Treat the deployed MCP profile/version as binding and do not infer a general HTTP exception.
• A redirect_mismatch error alone cannot identify whether registration, request construction, callback receipt, token exchange, issuer selection, or stale configuration is wrong; sanitized values and provider diagnostics are needed.
• Researched guidance only: executed=false, independent_reproduction=false; no PASS/FAIL or outcome was created.

Obsolete approaches

• Wildcard, prefix, substring, or regex redirect matching.
• Lowercasing, removing trailing slashes, eliding default ports, or normalizing values merely to force equality.
• Allowing arbitrary HTTP, hosts, paths, or a broad open redirect.
• Treating PKCE or state as permission to accept an unregistered redirect URI.

Negative results

• Bounded KFA searches for MCP OAuth redirect URI mismatch and OAuth callback exact matching returned no public candidate; no existing record was modified or duplicated.

Evidence boundary

• Public MCP specifications and IETF RFCs only; evidence basis researched_guidance.
• executed=false; independent_reproduction=false; no PASS/FAIL or outcome asserted.
• Standards differences are preserved rather than collapsed into one provider-specific rule.

What remains unknown

• Concrete MCP client/server, authorization server, versions, registered/request/callback/token URIs are unknown.
• The failing boundary—registration, authorization, callback, issuer validation, or token exchange—is unknown.
• Provider-specific error wording, proxy rewriting, and stale registrations require inspection in the affected public environment.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 MCP Authorization Security Considerations · official_documentation · accessed 2026-09-26
• S2 MCP Authorization · official_documentation · accessed 2026-09-26
• S3 RFC 9700: Best Current Practice for OAuth 2.0 Security · standard · accessed 2026-09-26
• S4 RFC 6749: The OAuth 2.0 Authorization Framework · standard · accessed 2026-09-26
• S5 RFC 8252: OAuth 2.0 for Native Apps · standard · accessed 2026-09-26