How client_id is protected alhough by using PKCE in native app

Secrets (client_secret) provisioned in client binaries cannot be considered confidentiat (rfc7636).

So I want to use the authorisation code flow with PKCE. That is designed for clients that don't use a client secret. I understand that PKCE ensures that the client is the same for the original authorisation code request and the request for the access_token.

Questions:

How is the client itself secured?
I give consent to a client(id). What if a malicious client uses my client_id and manages an user to sign in. Does that malicious client have the 'consent'?

Solution

Client side apps must be treated less secure than server side anyway. What authentication can do in that situation, is to ensure that the user is genuine. In particular, PKCE ensures that the user, started the app is the same, that entered the credentials within the mobile's surfing shell.

When you have "super-extra-sensitive-data-store" it would be better to build a middle level of protection, serverside yes, with a secret and certificate.

Some thoughts regarding the purpose we build the protection for. When we want to protect ourselves (or a 3rd party api) against a hacker, trying to break an app on own device, then we have no chances. When our goal is to protect a legal user running a valid app against some malicious code, then the device's and os's manufactures helps us with digital signature check and so on. Same with the web on desktop. Callback url just instructs the browser to go, but it can ignore the instruction when the user wants. So the only way to proof the app is to host it in a safe place.