Why OAuth + PKCE is the way to go to secure Mobile and Single Page Apps

If the concern is around using OAuth with non-confidential clients (SPAs or Mobile Apps), then the general recommendation is to leverage the OAuth Auth Code flow with PKCE (Proof Key for Code Exchange — aka “pixy”).

The problem with stand alone OAuth Auth Code when used by SPAs or Mobile Apps is that these applications can not maintain the confidentiality of either the Client Secret or the Authorization Code returned by the /authorize call (eg a malicious browser extension could capture the Auth Code from the address bar since it is returned by the OAuth Provider server through an HTTP 302 response). This allows for other malicious applications living on the same system to impersonate the legitimate app and exchange the Auth Code with an Access Token, then it is game over.

What makes OAuth Auth Code + PKCE more secure is that, during the /authorize call to the OAuth Provider, the SPA or Mobile App will randomly generate a code (code challenge). This code can not be leaked to a malicious app because it is just not stored in the app code or configuration, it is an one-time code that is randomly generated. It also can not be intercepted by a malicious application because the calls to the OAuth Provider use TLS.

When it is time for the genuine non-confidential client application to exchange the Auth Code by Access Token, this app will also share with the OAuth Provider a second code (code verifier) that will match (by calculation) the first code (code challenge). The OAuth Provider having previously recorded the randomly generated code challenge will only accept Auth Code exchanges when the /token call that contains the code verifier matches the code challenge that was shared with the OAuth Provider during the /authorize call.

From the RFC7636:

“To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called “code verifier”. A unique code verifier is created for every authorization request, and its transformed value, called “code challenge”, is sent to the authorization server to obtain the authorization code. The authorization code obtained is then sent to the token endpoint with the “code verifier”, and the server compares it with the previously received request code so that it can perform the proof of possession of the “code verifier” by the client. This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted.”