What surprised me here is not that OAuth can be bent into a phishing hole. That part is old news. What surprised me is how cleanly the article argues that the usual “just whitelist the client” answer is the wrong layer for MCP, because the thing you actually want to trust is not a brand or an app registration in the abstract, but a specific redirect destination for a specific user at a specific moment.
That feels like the right instinct. A lot of these systems collapse because they try to make trust an operator-only decision up front. Then real users show up with their own tools and the platform either says no, or it starts accepting arbitrary redirect URIs and hands attackers a neat one-click takeover path. The article’s design choice — let registration be permissive, but delay the trust decision until the authorize step when the user is known — is the part that made me nod. That is a more honest model of the problem.
I also think the open-redirect angle deserves more attention than it usually gets. People fixate on “can an attacker steal the code?” and forget that if your authorization server will bounce errors to an untrusted redirect URI, you have built a phishing and abuse primitive into your own domain. The article is pretty persuasive that this is not a side issue. If the server treats a bad scope or a failed PKCE check as something it can send away to the client, then the client’s redirect URI is already part of your trust boundary whether you meant it or not.
The per-user trusted redirect list is the interesting bit of engineering here. It is not magical. It does not make a malicious user harmless, and the author says that plainly. But it does seem like a practical way to let people connect their own agents without handing anonymous registrants a free pass. I especially like the constraints around changing the list only from the user’s own browser session, and the insistence on exact host matching. Those are the kind of boring rules that usually decide whether a security design survives contact with reality.
Still, I’m not fully sold on the UX tradeoffs. Requiring someone to type the host to trust it is a sensible anti-phishing friction point, but it is also the sort of thing users will resent the first time it interrupts a legitimate workflow. Maybe that is unavoidable. Perhaps the real test is whether the product can make the trust boundary visible enough that users understand why the friction exists, instead of just feeling blocked.
What I’d want to know next is how often this model breaks down in practice. The article makes a strong case that the alternative is worse, but it only hints at the messy edges: multiple clients on one redirect host, users who do not understand what they are authorizing, and the inevitable support burden when someone removes trust mid-flow and a code gets dropped on the floor. Those are not reasons to reject the approach. They are the reasons I would want to see it shipped carefully, with logs and clear refusal pages and maybe a lot of monitoring.
I came away thinking this is one of those unglamorous fixes that might actually be worth the complexity. Not because it solves phishing in general — it obviously does not — but because it narrows the problem to something the server can defend without asking every MCP operator to become an OAuth expert overnight.
Reference: MCP OAuth: let users trust their own redirect URIs safely
