RFC9700 spells it out about as clear as can be from the OAuth perspective. I can make sure similar language gets into OAuth 2.1.
Other than that, the MCP spec could definitely call this out more explicitly but that is a conversation that would happen over there. Aaron On Sun, Dec 7, 2025 at 6:03 AM Warren Parad <wparad= [email protected]> wrote: > I think the problem is well detailed there, but the problem for me is that > MCP is masquerading around in way that explicitly makes this a problem. > > I do also agree that redirecting after user interaction heavily lowers the > impact, as well as not redirecting the user in einem other cases. I will > say that historically, only the invalid redirect url was likely cause for > not redirecting. But one might say any configuration mismatch for DCRs > should treated incredibly carefully. I doubt many providers are thinking > about this. > > Put differently, is there a way we could help MCP oauth2 implementations > from falling into this pit of failure besides just letting them about it? > Is there a spec related change we could make? I'm not sure... > > On Sun, Dec 7, 2025, 14:54 Aaron Parecki <aaron= > [email protected]> wrote: > >> This is handled pretty well already in RFC9700: >> >> https://datatracker.ietf.org/doc/html/rfc9700#section-4.11.2 >> >> However, an attacker could also utilize a correctly registered >> redirection URI to perform phishing attacks. The attacker could, for >> example, register a client via dynamic client registration [RFC7591 >> <https://datatracker.ietf.org/doc/html/rfc7591>]and execute one of the >> following attacks: >> >> 1. Intentionally send an erroneous authorization request, e.g., by >> using an invalid scope value, thus instructing the authorization server to >> redirect the user agent to its phishing site. >> 2. Intentionally send a valid authorization request with client_idand >> redirect_uri controlled by the attacker. After the user >> authenticates, the authorization server prompts the user to provide >> consent >> to the request. If the user notices an issue with the request and declines >> the request, the authorization server still redirects the user agent to >> the >> phishing site. In this case, the user agent will be redirected to the >> phishing site regardless of the action taken by the user. >> 3. Intentionally send a valid silent authentication request ( >> prompt=none) with client_id and redirect_uri controlled by the >> attacker. In this case, the authorization server will automatically >> redirect the user agent to the phishing site. >> >> The authorization server MUST take precautions to prevent these threats. >> The authorization server MUST always authenticate the user first and, >> with the exception of the silent authentication use case, prompt the user >> for credentials when needed, before redirecting the user. Based on its risk >> assessment, the authorization server needs to decide whether or not it can >> trust the redirection URI. It could take into account URI analytics done >> internally or through some external service to evaluate the credibility and >> trustworthiness of content behind the URI, and the source of the >> redirection URI and other client data. >> >> The authorization server SHOULD only automatically redirect the user >> agent if it trusts the redirection URI. If the URI is not trusted, the >> authorization server MAY inform the user and rely on the user to make >> the correct decision. >> >> >> There's a big difference between "open redirection" and redirecting to a >> URL after some user interaction. So don't automatically redirect to a >> redirect URI that has been registered via unauthenticated DCR (or CIMD from >> an untrusted domain) with no clicks. That means if the AS typically would >> have redirected to the client with an error like "invalid scope", that >> should not happen here, as described in the section linked above. >> >> This is yet another example of how CIMD can help here without further >> complicating the client implementation. It's up to the AS to decide how >> trustworthy a domain is. So if the AS knows that "client.example.com" is >> a "good" client, then it can treat the redirect URIs in the CIMD as valid >> registered redirect URIs and redirect automatically on error conditions. >> Importantly, it's able to do this without adding additional client code >> like "software statements". >> >> Aaron >> >> >> >> >> On Sun, Dec 7, 2025 at 4:26 AM Warren Parad <wparad= >> [email protected]> wrote: >> >>> I'm currently working through a security review of MCP servers auth >>> implementations, and I'm stuck on something that I want a second opinion on. >>> >>> One challenge with OAuth implementations is potential abuse by becoming >>> an open redirector. However, with the validation of redirect URLs and >>> pre-registered clients, AS can know to block requests where redirects don't >>> match. This has the secondary benefit of blocking attackers from turning an >>> AS into an open redirector. >>> >>> With DCR, clients can register their own redirect urls, which means the >>> protection by AS vetting of redirect urls to clients no longer prevents >>> redirects to malicious urls. >>> >>> MCP server clients, (read: LLMs) which requires dynamic client >>> registration, and requires it without authorization (an initial access >>> token) to an AS, allows anyone to register malicious redirect urls. These >>> urls can be used to bypass the normal restrictions on AS being abused as an >>> open redirector. >>> >>> As long as MCP clients don't provide some sort of OIDC or pre-approval >>> for requests to DCR, do we in fact have a "serious" problem here? I say >>> "serious" because there is no security issue, but the conclusion I'm coming >>> to is that any MCP Server that exists necessarily requires an open >>> redirector unless they pre-validate a list of approved MCP Clients. >>> >>> I know there is the effort to create CIMD - OAuth Client ID Metadata >>> Documents, but I don't see that helps prevent this abuse. >>> >>> --- >>> >>> While, since this isn't a security issue unless someone goes out of >>> their way to enable all potential untrusted LLMs to register clients, and >>> even then there are no security concerns, this abuse is not something that >>> I think should be left unchecked. >>> >>> I would appreciate at least a double check on my thinking here. >>> >>> Thanks, >>> Warren >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
