1

Ok so I get the benefit that PKCE provides. Without it, the attacker knows your client_secret and by registering the same URL scheme as your application on mobile, can intercept the redirect with the auth code, and then use it along with your client_id and client_secret to receive an access token to the user's resources.

However with PKCE, the only thing that the attacker now needs is your client_id. They can generate their own PKCE. On intercepting the redirect, they can now use the auth code received along with the client_id and code_verifier (since they generated the PKCE themselves) to get the access token.

So my question is:
Is the only thing that prevents an attacker from doing this, is that they still need to direct the user to the identity provider to authenticate, and in doing so, the user would see that the identity provider is requesting them to supply permission to your app, which is different to the (malicious) app they came from? Or is there another blocker?

Ash
  • 111
  • 6
  • The attack you describe will not work. You suggest the attacker intercepts the redirect with the auth code. However, the Authorization Server will only redirect the user to prior registered redirect_uri's. RFC 6749, 10.6: "The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value." – Matthijs Melissen May 20 '22 at 23:57

0 Answers0