Why is PKCE secure against man-in-the-middle attacks?

Question

In attempting to implement OAuth2 into a natively installed client application, we face the problem that we cannot securely store the pre-shared client secret. After doing some research, I came across PKCE, which I had not previously heard of. Swapping out the client secret for a short-lived nonce seems like a reasonable idea to me, but I can't figure out how we protect against what seems like a fairly clear man-in-the-middle attack. My thinking is thus:

The flow starts with Alice sending bob a hashed code challenge along with some assertion of her identity (like a session token). The challenge is hashed because it cannot be assumed to be secure. The server stores the hashed code challenge but otherwise follows basic OAuth2 and returns an authorisation code. All good so far.

The next step is for Alice to send the authorisation code and the now un-hashed code challenge back to Bob, now all encrypted in an HTTPS POST request. Bob can validate the code challenge by hashing the value and comparing it with the previous hash, and generate an access token for the authorisation code.

I understand that the reason this is "more secure" is because an interceptor ("Eve") would not have the plain text code challenge value in the second step, and thus, even if they heard the authorisation code, wouldn't be able to request an access token. My concern is, though, could Eve not just intercept the initial request and swap out the hashed code challenge for the hash of challenge she created herself? (In practice, I would imagine this being something akin to returning a false 302 response which redirects the user with a swapped out hash in the QS)Then the authorisation code would be associated with that challenge and not Alice's!

I've gone round this a few times and flip flopped between being happy I've understood it and not convinced, so it's probably a case I've thought about this too much. But if someone could explain why I am wrong in plain English I would much appreciate it :)

Thanks in advance!

Answer 1

Such a man-in-the-middle attack is prevented by the use of TLS.

RFC 6749, section 3.1 (OAuth 2.0 Authorization Framework) explicitly states that TLS MUST be used for the communication with the authorization endpoint. And even the introduction of RFC 7636 (PKCE) states the following when referring to the authorization request that returns the authorization code:

Because OAuth requires the use of TLS, this communication is protected by TLS and cannot be intercepted.

The use of TLS (or IPsec) is further recommended for any OAuth communication by the security considerations described in RFC 6819, see section 5.1 (in particular the first two sub-sections).

The part that PKCE protects against is the possibly unprotected communication to the redirection endpoint. For native apps the custom URI scheme generally used might also be registered by a malicious app, allowing it to intercept the authorization code. But without code verifier it won't be able to request an access token.