CODEWITHSUNDEEP
oauth-2.0openid-connectpkce
johis69854
johis69854

Reputation: 53

In the OAuth 2.0 Authorization Code Flow with PKCE what prevents intercepting the code challenge on the first call to the auth server?

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?

Upvotes: 5

Views: 2511

Answers (2)

Justin
Justin

Reputation: 86779

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?

Upvotes: 3

MvdD
MvdD

Reputation: 23486

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.

Upvotes: 4

Related Questions