According to https://www.linkedin.com/advice/0/how-does-pkce-prevent-authorization-code-interception-attacks#why-use-pkce?
The attacker can then use the stolen code to request an access token from the token endpoint, impersonating the legitimate client. This is especially risky for public clients, which are applications that cannot store a client secret securely, such as native or single-page applications.
If the attacker has control over the user in a way that can prevent use of the authorization code, what's to stop them from obtaining the PKCE challenge too?
They obviously have complete control over the client.
PKCE is there to ensure that it is the same client(application) that does both the initial authenticaton request and the request with the authorization code.
For example, in mobile apps or browser extensions, if a "evil" app gets the authorization code, then it should not be able to use it.
The problem is that multiple apps might try to register for the same redirect_uri in a mobile phone for example.
How can a hacker capture the redirect?
Mobile applications often register a custom scheme to receive the redirect request back from the STS:
app-name://?access_token=??????
For example:
com.googleusercontent.apps.123504760640ip7qq628i6dreavptfk981d9ji6x:/oauth2callback
com.googleusercontent.apps.5996697-7obf9q7equ9msfakdcg8iveqgn3sck1s:/oauth2callback
fb19884028963vimeo://authorize/fb1592193007691679://authorize/
x-msauth-azureiosapp://com.microsoft.azure
ms-whiteboard-iosauth://com.microsoft.whiteboard
mevo://vimeooauth
oreilly://oauth/complete
What if the hacker also registers the same scheme?
The clientID, the hacker can easilly by capturing a sample request from a mobile application.