[OAUTH-WG] Re: MCP DCR redirect urls as open redirectors

[Warren Parad <[e-mail]>]

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=[e-mail]>
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=
> [e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>