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 <[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]
