aaronpk
The storage problem with JS apps has nothing to do with PKCE. PKCE protects the data sent in the redirect, which is a different attack surface than stored tokens.
Put yourself in the shoes of the authorization server issuing the access token. If you send an access token to the application by sending it in an HTTP redirect, you have no idea whether the application has actually received that access token, or what may have stolen it via the redirect in the process. For example, this browser extension will show you any sites that you log in to that are using the Implicit flow: https://github.com/oktadeve… It turns out that any extensions you have installed could already be siphoning off access tokens without your knowledge.
By using PKCE, the authorization server issues a one-time code in the redirect, and the application has to confirm receipt of it by making the separate POST request for an access token. If someone were able to steal the code from the redirect, they wouldn’t be able to use it to get an access token thanks to the PKCE mechanism.
Now, once the app has the access token, whether it got it from the implicit flow or using PKCE, the problem is now how it can store it in a secure way. This problem exists both with the implicit flow and with PKCE, and you’re right that it is mostly an unsolved problem with browsers. But, PKCE solves a different, more important problem, so it is useful.
I explain this more in this video: https://www.youtube.com/wat…