[jodersky]

Yes indeed, you are right that this is not part of the implicit flow mechanism.

AFAIU, the recommendation from OAuth 2.1 is to drop the use of implicit flows in web apps and instead rely on code flows with PKCE. The idea would be that the web app registers itself as a so-called "public client" (see https://oauth.net/2/client-types/) when it is loaded and then uses the standard code flow with PKCE.

[mooreds]

I wrote a doc about the differences between OAuth2 and (proposed) OAuth 2.1, which might be helpful: https://fusionauth.io/learn/expert-advice/oauth/differences-...

It was based on this section with expanded examples: https://tools.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name...

The implicit flow is bad for exactly the reasons mentioned: it exposes the access token (which is typically a bearer token) to the wild west environment of the browser. There are safe ways to have a token in a browser (as a secure, HTTPonly cookie, for example) but delivering the token in such a way as to allow any JS running on the page to have access to it is not one of them.

Having a server side component which holds the client secret and can safely do the exchange buys you security, but it also buys you architectural flexibility. You can decide where the token should live (on the client, sent down as a cookie or to be stored in memory or on the server, using the BFF pattern and sessions to tie the client to this token).

[littlecranky67]

> but it also buys you architectural flexibility

Yes but it comes at a cost, that you always have to have a backend component for this auth/token exchange in your stack - even when relying on 3rd party SaaS auth providers. I use AWS Cognito for signup + login, and just to make the "code flow" available I had to introduce server-side services in NextJS using NextAuth. I attach the access token then to the session and send it back to the browser/SPA. Now, the access token is used for a broader range of services (different tech stack, different programming languages) that are directly called from the browser through Ajax. What bugs me with this setup is, that my FE is 100% SPA - so in theory I could just export the full NextJS project to static html and host it on a CDN. But the NextAuth service required for the code flow breaks this. I am going with it for now, but depending on hosting costs in the future (I have to run a separate server now for NextAuth vs. hosting static files on a cheap CDN), I might go back to implicit flow, and kill the need for a custom auth-service. Especially that I don't feel it is much safer now - if anyone can gain access to my nextauth server, all tokens will be compromised for all users. With the implicit flow I am no longer responsible for this security, and can rely on AWS/CDN being secure.

[l72]

> There are safe ways to have a token in a browser (as a secure, HTTPonly cookie, for example) but delivering the token in such a way as to allow any JS running on the page to have access to it is not one of them.

This always bugs me. Why is anyone creating an SPA (or any client mobile/desktop application) where they don't trust the code running in their own application? It just seems crazy to me to include dependencies/libraries that you can't trust.