ctron
commented
4 days ago Interesting and valid use case. Though that's something which is not supported out of the box at the moment. I could imagine having a second entry point, sending OIDC tokens/state between windows somehow. What would mean we'd need some way to serialize and deserialize state. Like having an "import state" function.
If an SPA doesn't need logins unconditionally and has volatile state, it may be a good idea to do the OAuth login in a separate window (or tab, same thing). For a concrete example I'm building, a Web Bluetooth connection is established, and only during that connection the application learns whether or not a login is needed. If the login goes through a redirect, the page winds up in a freshly loaded state, and while a lot of application state can be persisted easily through the nested router, Web Bluetooth connections are just gone after a refresh, and it takes a nontrivial amount of user interaction to get them back (ie., starting the connection can only be done from a user interaction like a button press, then there's a popup to select a device from a list (which the application can make an effort to limit to 1), user selects the one and confirms).
An alternative is opening the login in a separate window, and making the redirect URI close the window again. To my understanding of OAuth / OIDC, that's generally supported, but the current
start_logincode sets thewindow.location.I can give this a shot later -- my approach would be to add an item to the LoginOptions that says
new_window(or maybetarget, which is at least what these things were called back when we followed links with<a href="…">…</a>). Of course, the sensible values of redirect targets would then be vastly different, but I trust that there can still be good defaults for that case.