4

This question is essentially the opposite of Why isn't PKCE encouraged for Single-Page Apps?.

In recent years, most OAuth API vendors seem to be have become unanimous in recommending that JavaScript apps without a server backend (a.k.a. SPAs) use a proof-key-for-code-exchange grant flow (PKCE, as documented here).

What I'm curious about is why that change came about.

It's easy to understand why PKCE is needed in native apps, where things like custom URI schemes are used to collect access tokens, which is a vector for token leakage when any app on your OS can potentially register itself as a handler for your URI scheme.

But what are the weaknesses in a browser app? Referer headers? Extensions? History leakage? Some other vector I haven't thought of but which evil hackers will swoop in to exploit mere minutes after my site goes live?

(For the record, I have no particular aversion to using PKCE, I'm just really interested in the security context and would like to get better at reasoning about weaknesses in front end applications)

Jimmy Breck-McKye
  • 151
  • 5

2 Answers2

1

PKCE ensures that the client which requests a token is still the same one which started the authentication request. Beside a malicious extension, this Draft also names the risk of CSRF which is avoided with PKCE: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-05#section-7.1 You shouln't accept an attackers auth code on your SPA redirect URI. This would establish the use of the attackers resources at the victims app session. The victim could enter secret data stored at the attackers resources.

Community
  • 1
Johannes B
  • 156
  • 2
1

It's not and you should not use it. Vendors they ship you and sdk or js library but they don't know if you will use it in an intranet secure environnement or in a public internet portal.

THe principe of PKCE is that for every request you generate a random hashed secret that you can send to the authentication server. The problem here is that this secret will be stored in JS, so vulnerable. A better way is to have a Backend for font end or implement the Token handler pattern. store all keys in httpOnly cookies

riadh
  • 111
  • 1