Stream Vessel proposes per-user trusted redirect URIs to let custom MCP clients sign in safely

A registration wall for custom clients

MCP clients sign in with standard OAuth: the client registers itself, opens a browser, the user clicks Approve, and the client swaps a one-time authorization code for a token. For anyone running their own agent — a Slack bot, a service on a VPS, a weekend MCP client — the flow often dies at step one. In a November 4 post on the Stream Vessel blog, Alexander Loginov describes the failure: the server rejects the client's redirect URI, the address the browser returns to carrying the code, because it is not on the operator's allowlist. Those lists typically cover only well-known clients such as Claude, ChatGPT, Cursor and VS Code, and adding another means asking the operator to edit a config file.

The list cannot simply be dropped, either. It is the only guarantee that an approval means what the user thinks it means: whatever the client calls itself, the keys can only go where the list says.

The attack an open server invites

According to the post, a server that accepts any registration and any redirect address lets an attacker take over a user's access in four steps, with no account needed: register a client named “Claude” with an attacker-controlled callback, send a signed-in user a plausible authorize link, let the user approve on the real consent screen in their real session, and collect the code at the attacker's address, where it becomes a token.

PKCE does not help because the attacker started the flow, and the client name is self-declared. The pattern mirrors the fake-app approval prompts aimed at Microsoft 365 users.

The chain is documented. A May 2026 study that tested 119 OAuth-enabled MCP servers found registration endpoints on 114 of them — 95.8 percent — that accept arbitrary redirect URIs from anonymous requesters. Obsidian Security reported the same chain against Square's MCP server in January 2026, exposing a merchant's profile, transactions and bank details with one click; the researchers noted that Square's fix only covered newly registered clients. Others found it against an MCP proxy in front of single sign-on, worth a 24-hour access token and a 14-day refresh token per click, and across bug-bounty programs, where it was sometimes dismissed as social engineering.

There is a quieter side effect: when a request fails a check after its redirect address was accepted, the error is sent to that address. A server accepting any address becomes an open redirector on its own domain, a case RFC 9700 spells out.

Spec and practice pull in opposite directions

The MCP spec requires servers to validate exact redirect URIs and recommends redirecting automatically only to URIs they trust, borrowing those latter sentences from RFC 9700, but it leaves what counts as trusted to each server. Registration is also shifting: the 2026-07-28 client registration page deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, where the client id is an HTTPS URL listing the client's redirect URIs. As Loginov notes, that establishes who publishes a client, not whether this user meant to connect it.

In practice, the post sees servers at one of two poles. A fixed operator allowlist — pgEdge's Postgres MCP server, for instance — keeps exposure low but admits only listed clients. Accepting whatever the client registered, as 114 of the 119 tested servers do, admits everyone and enables the attack above. The closed pole has real casualties: a June 2026 Claude Code issue reports that organizations with exact-match allowlists cannot sign in from Claude Code because its localhost callback host and path are fixed; it was closed as not planned.

Per-user trust, decided at sign-in

Stream Vessel's proposal keeps the operator allowlist and loopback URIs for local clients unchanged, then adds a second layer: each user can trust a small set of exact HTTPS redirect addresses for their own account, capped at ten, managed as “Trusted app addresses” on the MCP page of the web app and changeable only from the user's own browser session.

Timing is the key move. Registration happens before anyone signs in, so it cannot know whose list to consult; it accepts any HTTPS URI, and the decision waits until the authorize page, where the user is known. One rule sits under every branch: no code and no error is ever redirected to an address that every account or this particular user does not trust.

The post acknowledges precedents — GitHub's developer-entered callback URLs, the MCP spec's manual pre-registration option, Atlassian's per-organization trusted domains — but argues none of them fit a client that registers itself anonymously without a client id made elsewhere or an admin deciding for a whole organization.

Why it matters

The May 2026 measurements suggest most deployed MCP servers have already chosen openness over safety, while the locked-down ones strand self-hosted agents. Anyone operating an MCP server in front of real data faces this trade-off, and a single approval click should not hand an account to an attacker. Per-user trusted redirect URIs reframe the question from whether a client is well-known to whether this user meant to connect it, and the design is simple enough for other server operators to copy.