[DaiPlusPlus]

The problem isn't about secure transmission of the access_token, it's about secure storage of the access_token: it's impossible to safely and securely store secrets in browser-based (JS) OIDC clients when using OIDC's Implicit flow, which is the only flow that works with client-side-JS applications (especially SPAs).

Conventional web-applications let the application server store per-user secrets (e.g. access_tokens). If the application server needs to be stateless then secrets are packed into a web-browser cookie with the "httponly" and "secure" attributes which prevents any and all client-scripts from accessing them. Of course browser cookies are not the same thing as a true Bearer Token, so this means that when using an SPA the SPA cannot make its own HTTP requests to other RPs, it needs to use some non-local secret-storing-proxy to make the request for it... which starts to make a mockery of how microservices should operate.

Code Flow with PKCE does not replace the Implicit flow. Also, the Auth0 article you linked to is not a "good job". On the contrary, that article talks about using client-secrets - which you *must never have* in a JS-only/SPA/static client.

The only real solution would be some kind of opaque OIDC client built-in to a browser that handles secrets-storage on-behalf of JS applications (such that JS code never gets to see or handle any secrets, including the auth code and access_token, but the OIDC identity_token should be exposed, of course). I'm surprised Google and Mozilla haven't done this already...