The idea behind mitigation of OAuth 2.0 code interception attacks
If you have ever heard about the OAuth 2.0 protocol, it is very likely that you came across the “PKCE” term. So, what is “PKCE”?
As stated in the standard:
What can be done about this? This is where “PKCE”, which stands for “Proof Key for Code Exchange”, comes into play. To mitigate this attack, a dynamically created high-entropy cryptographic random key called “code verifier” is uniquely created for every authorization request, from which a transformed value is derived, called “code challenge”. These values are then used in the communication with the authorization and the token endpoint.
To understand how this helps to mitigate the issue take a look at this flow:
In the diagram above the client creates the “code verifier” and the transformed value, the “code challenge”. Then, sends the “code challenge” and the transformation method along with the Authorization Request . The Authorization Endpoint receives the Authorization Request, records the “code challenge” and the transformation method and returns the authorization code. The client then sends an Access Token Request with the authorization code and the “code verifier” to the token endpoint, where then the “code verifier” is transformed and compared to the “code challenge”. If the comparison shows the values are not equal, access is denied.
And that’s it in a nutshell :). If you want to learn more details and educate yourself further, check out the “Proof Key for Code Exchange by OAuth Public Clients” specification referenced below.
