Validate MCP Localhost Redirects

A desktop MCP client may use a loopback redirect to finish OAuth authorization. The URI can include a local port chosen for that run. Treating every localhost URL as interchangeable invites code interception or a callback delivered to the wrong process. The MCP security guidance discusses local redirect risks, and the authorization flow still needs issuer, state, and PKCE checks.

Define exactly which client types may use loopback redirects. A hosted web client should not borrow the desktop exception. Register the allowed scheme, host form, and path. Decide how the ephemeral port is selected and bound before the browser opens. The local listener should accept only one matching response and close promptly.

Redirect review table

Do not use a wildcard that accidentally accepts a public hostname ending in localhost. Normalize addresses carefully and compare parsed URI components, not a substring. Keep the authorization code out of logs, crash reports, and model context. A loopback redirect is a local transport convenience, not a grant to the MCP tools.

Owned-client test

In a controlled desktop test, bind the listener, start a login, and complete one valid callback. Verify the code is exchanged only once and the listener closes. Replay the same callback, change its path, and send a response with a wrong state value. No token should result. Repeat with a second process trying to claim the port before the intended client binds it; the client should fail rather than continue on an unverified listener.

Record the callback URI shape, binding order, issuer comparison, and outcome without capturing a real authorization code. If the implementation depends on a provider-specific redirect exception, document that limit. Do not loosen all redirects to make one client work. A successful browser return is only one step; the token still needs audience and scope validation at the MCP server.