I may be missing something, but it seems like the sample code would not provide any additional protection against tokens being leaked via a malicious browser extension, which seems to be the main anecdotal attack vector mentioned in this article.
Sure, it removes token from being in the browser history, but it just moves it to
localStorage by default (if I’m reading the docs correctly).
Wouldn’t that leave your SPA just as vulnerable to that particular attack vector? A browser extension that can access browser history could presumably access any of those storage options listed in the
okta-auth-js docs just as easily.
In fact, this other post from Okta seems to confirm my suspicion:
At first I thought one benefit might be that not exposing the token in the URL of a redirect would prevent a MITM attack, but this is a moot point, as the example in this post put the token in the URL fragment, which would not be sent in the HTTP request.
It seems like the primary benefit of PKCE is not that it would prevent leakage via a malicious browser extension or XSS, but that it protects the authorization code from being stolen to obtain a token: at the end of the flow, you still have all the problems inherent to storing sensitive data in the browser.
Does that sound correct to you?