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!

  • Is there a reason you assume the initial exchange between Alice and Bob is not protected by TLS? – ecdsa Apr 1 at 12:16
  • I believe that under OAuth2 you cannot assume it would be - a quick glance at the spec suggests that this is the case by absence of mention - and I believe that one of the ideas of OAuth2 was it doesn't rely on it. Also in my particular case, it almost certainly would not be, due to the nature of the native app. – Raiden616 Apr 1 at 15:19

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.

  • Ah okay, I missed that sentence in RFC 6749. That said my security concerns haven't really been quashed; I'm still concerned about: a) QS parameters being insecure even under TLS; b) An impersonating application. But after doing a bit more reading (hackernoon.com/strengthening-oauth2-for-mobile-f4f3925dbf18 and web-in-security.blogspot.com/2017/01/… illustrate some of my concerns), I've concluded that basically the answer is: it's not. But you've answered my question in terms of with what PKCE DOES help, so thank you very much for your time. – Raiden616 Apr 3 at 10:06
  • How is a) a problem with TLS? Or are your referring to the redirect on the client? And b) is technically not a MITM attack (RFC 8252 might have more information on mitigating such attacks). – ecdsa Apr 3 at 14:25

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.