0

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.