3

I feel like I am missing an important point here, I have been reading up a bit on the PKCE flow but something doesn't sit quite right.

How is PKCE secure on public devices? If I understand this correctly if you do not control the redirect url then anyone can pretend they are your app. Suppose the redirect is localhost/foo, if you initiate the flow by exchanging a client-side generated secret and a clientid embedded in the client, what is stopping a malicious app from taking my clientid and redirect and pretending they are my app? The secret is dynamic so that is not a stopper, the redirect is available to anyone and the clientid is embedded client-side.

What am I missing?

1 Answer 1

4

Proof Key for Code Exchange (PKCE)
A public client cannot store client id/secret in a safe way, thus the code has to be seen as a bearer token. If an attacker gets the code, without PKCE nothing hinders that this code can exchanged for a token.

As decribed in RFC 7636, PKCE bindes the Authentication Request to the Token Request. A stolen code cannot be traded for a token, since the attacker does not know the the code verifier.

Client Impersonation
It is not PKCEs goal to protect against client impersonation. As you correctly explained, an attacker can simply impersonate a public client that uses PKCE.

The authorisation server must use other techniques to prevent the impersonation of public client (that cannot be authenticated due to their nature), as stated in the RFC 6749 (OAuth 2.0):

If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .