My understanding is that client impersonation cannot be prevented for Native Desktop Apps. If all standard controls: State, PKCE, Redirect_URI confirmation etc are in place, to prevent auth_code leakage or injection. Then the only way an attacker could reasonably compromise a flow is if they are capable of manipulating the initial request. Specifically by PKCE downgrade attack or challenge_response substitution.
This would allow the attacker to intercept the response, and exchange the auth_code for and id_token. They would then be able to impersonate the user associated with the id_token to an external resource (backend server).
This would require a compromised app that is capable of interfering with the initial request (malicious browser app), or a malicious native app that impersonates the valid app outright.
To me this is no different than if a malicious app is able to record key strokes and is then used to steal credentials on a web page. The security concerns appear to be about the same, in that it requires a device to be compromised in a specific indefensible way.
Question: Can a validly signed id_token from a public native desktop app be considered a form of authentication equivalent to a standard username/password sign-in?