Right, but that seems preferable if I'm doing this all client side? Yes, an access token could get leaked in the URL. But sending the refresh token to the client feels far more dangerous.
I think that is the only way to do it if you use any openID connect implenmentations - which is often my criticism about it. Modern browsers can have cookies using SameSite=strict and HttpOnly cookies, which I would consider better than storing refresh tokens in localStorage or even expose them at all to javascript. But OpenID Connect predates those browser features, so everyone seems okay with it.
My scenario still makes it impossible to use those, sadly. Specifically, I do not have any servers involved. Completely static javascript served up through s3, basically.
If my threat model gets to where I care about this, I suppose my only real options is doing the redirect to a compute backed address. For now, glad I don't have to worry about it. :D
I had the same setup and was dissapointed with OAuth/OpenID Connect same as you, as there is NO way to make that work with modern flows. Your only option is to use the implicit flow and store refresh/access token in localStorage.
The "modern" code flow involves a piece of backend code that performs the exchange of the code for tokens - and you are actually not supposed to make those token available to the (insecure) browser.
Being fair, the code flow can be done on the client. And it does protect from most of the URL sniffing attacks that are there for the implicit flow. It just feels weird to still be doing all of that from the client.
I'd be genuinely interested how you can do the code flow on the client (browser). So far, all OAuth providers I tested will not let you do that due to CORS issues.
