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]
