A web-based MCP client registers the redirect URI http://app.example.com/callback with an authorization server, and the server accepts any redirect URI that starts with the registered prefix. What is wrong with this setup?
Select an answer to reveal the explanation.
Short Explanation
Two holes, not one. A plain-http callback on a public host lets anyone on the path grab the code, and prefix matching lets an attacker tack on their own path and catch it. You want HTTPS (or localhost) and an exact, character-for-character match.
Full Explanation
The authorization security considerations on communication security require that all redirect URIs MUST be either localhost or use HTTPS, following OAuth 2.1. Under open redirection, clients MUST register their redirect URIs with the authorization server, and authorization servers MUST validate exact redirect URIs against the pre-registered values to prevent redirection attacks; MCP proxy servers likewise must use exact string matching, not pattern matching or wildcards. Both flaws in this setup therefore need fixing. Treating the setup as acceptable because the resource parameter is sent confuses audience binding with redirect safety; RFC 8707 resource indicators bind a token to the MCP server but do nothing to stop an authorization code being delivered to an attacker-controlled path. Allowing plain http for a public production hostname exposes authorization codes to interception. Calling prefix matching the recommended approach inverts the rule, since a prefix lets an attacker append a path they control under the registered host. Exam caveat: localhost redirect URIs are allowed but carry impersonation risk, so authorization servers SHOULD warn on localhost-only clients and MUST display the redirect hostname. Operational check: attempt an authorization request with an altered callback path and confirm the authorization server refuses it.