Sure, but a question could be"what are people doing to get around this?" Or "knowing that people can't get around this, can we do something else?"
On Sun, Dec 7, 2025, 15:05 Aaron Parecki <[email protected]> wrote: > 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_id >>> and 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]
