OAuth design flaws with open dynamic client registration

[Shridhad]

Summary of the attack

1. Attacker registers a malicious OAuth client using the public /register endpoint. This endpoint lets them define their redirect_uri
2. Because the redirect_uri is under their control, they can initiate an OAuth authorization flow using the malicious client.
3. When a victim clicks a specially crafted link (with the attacker's client_id and redirect_uri), the victim is redirected to the attacker's domain with a valid code.
4. The attacker can now exchange that code for a valid access_token, as:
   1. They control the client_id and redirect_uri
   2. They generated the PKCE code_verifier themselves
5. This lets the attacker impersonate the victim, as the access token reflects the victim’s session and authorization.

Neon's OAuth server does show a warning to the end-user/victim about the dynamically registered clients in call cases with client_id, client_name, and redirect_uris; however, this is not enough to prevent this impersonating attack.