5

Imagine this attack

  1. An attacker intercepts the first call to the authorization server, then they have the code-challenge. (step 1 in the diagram)
  2. The attacker now intercepts the response from the authorization server with the authorization code. (step 2 in the diagram)
  3. Then the attacker can POST the authorization-code and the code-verifier to get the access token. (step 3)

Refer to this diagram: flow:enter image description here

Questions

  1. What prevents the attacker intercepting the first call to the authorization server? This is what is meant to make authorization code + PKCE more secure than implicit flow.

  2. Perhaps it does not matter if the call is intercepted because the code-challenge is hashed and therefore the attacker does not have the code-verifier required for the 2nd call. But what if the code-challenge is not hashed?

N. berouain
  • 1,181
  • 13
  • 17
johis69854
  • 53
  • 6

2 Answers2

3

PKCE is meant to assure that the client that requested the user to be authenticated, it the same client that exchanges the authorization code for an access token.

All communication with the authorization server is using HTTPS, go it's difficult to intercept. But some mobile platforms allow (malicious) apps to register the same redirect_uri as the legitimate client. This meant that when the authorization server redirected back to the client with the authorization code, both the legitimate client and the malicious client would be called with the code. This allowed the malicious client to exchange the code for an access token, since no client authentication is done.

PKCE solves this by including the code_challenge in the authentication request, which is a hash of the code verifier. It then requires the actual verifier in the token exchange call. The malicious client does not have the verifier and can therefore not authenticate itself and thus not exchange the code for a token.

MvdD
  • 22,082
  • 8
  • 65
  • 93
  • So without PKCE you just register another, malicious, app with the same redirect_uri and when the legitimate app calls the authorization server to request an authorization code your malicious app also gets called? That sounds horribly unsafe, or did I misunderstand something here? – Boommeister Feb 05 '21 at 11:56
  • 1
    Not sure. The issue is that a malicious app installed on your phone could register the same activation URL as your banking app (phone apps typically use a custom scheme for activation URLs). In that case, they would be activated on the same redirection URL as your banking app and could retrieve the authorization code from the URL. – MvdD Feb 05 '21 at 18:49
3

PKCE is meant to address the threat of the access token / authorization code being leaked from URL, which is relatively likely compared to an attacker intercepting SSL traffic:

  • URLS are visible in the address bar
  • URLs are saved in the browser history
  • On native platforms multiple applications may be registered to use the same custom URI scheme

That said, its recommended that the code challenge be a SHA256 hash of the code verifier, therefore even if the attacker were to intercept the code challenge, they would be unable to complete the token exchange without being able to reverse SHA256.

Also see: What is PKCE actually protecting?

Justin
  • 84,773
  • 49
  • 224
  • 367