What does PKCE actually do to help with security?

Question

So I’ve been working on an app with three OAuth2 providers and I remember Microsoft being a breeze after figuring out where the documentation was. Should be easy - it’s just MSAL like I was using it before, right?

Except now, the code samples are longer because all the documentation comes with PKCE code. No other provider had this in their docs at all, and Microsoft seems to almost be forcing you to. But I read further into it, and the question shifts from why Microsoft only documents this implementation for the authorisation code flow to if PKCE even does anything for security. The security it grants appears to be minimal at best - if PKCE is there to prevent browser extensions and injected code from interfering, why does it use data that can be read from injected code or a client? All it takes for this to become useless is for a bad actor to analyse how the codes are handled, and build their malicious code to take the verifier and use it.

I asked Azure Support about this on Twitter, and they didn’t know how PKCE could help despite this. I know the people making the standards put thought into this and if they say something helps, it probably helps, but what does this one really protect against?

Answer 1

Hi @⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

It seems that Microsoft has thought through the process of using PKCE to mitigate OAUTh 2.0 interception attacks.

The following link (below) gives a glimpse to why Microsoft has potentially adopted the Proof Key for Code Exchange by OAuth Public Clients (RFC 7636) standard.

OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack. This
specification describes the attack as well as a technique to mitigate
against the threat through the use of Proof Key for Code Exchange
(PKCE, pronounced "pixy").

https://www.rfc-editor.org/rfc/rfc7636

More information found at https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#request-an-authorization-code

More information on PKCE for OAuth 2.0 can be found at:

https://oauth.net/2/pkce/

PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks.

PKCE is not a replacement for a client secret, and PKCE is recommended even if a client is using a client secret.

Note: Because PKCE is not a replacement for client authentication, it does not allow treating a public client as a confidential client.

PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use a client secret.

---

If this is helpful please accept answer.

Answer 2

Hello @⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ and thanks for reaching out. MSAL samples remain mostly the same since PKCE is handled internally without immediate need for developer intervention. PKCE finally provides SPA and public apps a secret, albeit one restricted to only one (full) authorization request which greatly limits any attack scope. Also, it provides Web apps and confidential clients with an extra secret, effectively doubling the security.

Let us know if you need additional assistance. If the answer was helpful, please accept it and complete the quality survey so that others can find a solution.