Letting users trust their own MCP clients, without opening a phishing hole

The piece examines a tension in OAuth for MCP servers: fixed redirect-URI allowlists can block users’ own agents, but accepting any address lets attackers register a fake client and send a victim’s authorization code to an attacker-controlled site. A May 2026 study found that 114 of 119 tested OAuth-enabled MCP servers accepted arbitrary redirect URIs. The resulting attack can expose a user’s data after one convincing approval, and PKCE does not prevent it because the attacker initiates the flow. Unrestricted redirects can also turn a server into an open redirector. The MCP specification requires exact URI validation but leaves the meaning of a trusted destination to server operators; newer client-registration standards do not establish whether a user intended to trust a client.

The proposed approach keeps operator-approved redirects and localhost callbacks available to everyone, while letting each user trust up to 10 exact HTTPS callback addresses for their own account. Registration accepts addresses before a user is known, but authorization checks them after sign-in. If an address is not already trusted, the server refuses on its own domain; the user must type the displayed host to trust it and retry. Consent identifies the specific callback and why it is trusted, while additions trigger email and audit records. Removing an address revokes related grants and pending codes. The system also rejects ambiguous hostnames and avoids wildcards or loose matches. It cannot stop someone who is persuaded to trust an attacker, but adds friction and warning signals; consent defaults to read-only.