Just witnessed the new authentication flow on matrix.org in Element and it's so bad it managed to scare me that I somehow got phished, doesn't handle multiple profiles and doesn't work at all when there's no handler registered in the user's browser (there's no fallback!). I'm also amazed at how it launches the auth flow in an external browser (causing all these issues) despite of Electron being... a browser.
@dos Eh, that's just SSO/OAuth2, I don't really see the problem with it?
@bart It's how it only implements the happy path and fails to consider anything deviating from it. I literally couldn't login today without hacking up a script to point the browser to because there was no way to pass the token back to the running Element instance.
@bart And that's just the beginning - just clicking on the button that initiated the passing of the token was enough for it to consider it consumed, so it errored out on retry - but that did not stop it from considering the session active and listing it in the panel, with "last activity" suggesting that the authentication actually succeeded somewhere else 😱
@bart It turned out to be just a careless OAuth implementation, but it did manage to scare me for a moment.
@bart Compare it to, for example, the flow in Tuba and Mastodon, which tries to do the same thing by default, but recognizes that it may not work and gives you the option to copy the authorization token back to the app manually. No such thing in Element.
@dos @bart Hey! I'm the developer who introduced OAuth in Matrix. Getting the redirect back to native client is a very complex topic, and also highly dependant on how the native app is being shipped.
This is especially a problem on Linux where Element doesn't maintain the many of the packages themselves, plus the many ways to run it (Flatpak, snaps, community repos), so we have no guarantee that the custom scheme handler is correctly installed.
When I implemented the redirect back to the client, I foolishly assumed that a HTTP redirect to the native scheme was enough; which was the most convenient way to have the whole flow JS-free
@dos @bart I'm looking for a few ways to improve the flow in those edge cases. One way is to consider the Device Code Grant (https://github.com/matrix-org/matrix-spec-proposals/pull/4341) in cases where we're not sure the redirect will work.
Another thing is to give a nice proper link to users to get back to their client instead of relying on an HTTP redirect that can't be replayed. The suggestion to give out the code to copy back to the client as a last resort is interesting, even though ideally we should really not need those kind of potentially confusing workaround :(
@dos @bart I know this is probably not the answer you would like to hear (nor one I'm really happy giving) but part of the truth is, we're really resource constrained, and sometime cannot afford spending resources to fix problems that don't affect customers paying us (this one mostly affects Linux users on community packages). It's on my personal list of 'things to do/fix when I have spare time', but that list is long and spare time is not something I have much of :)
@quentin @bart Hey! Thanks for replying and sorry about my ranty tone 😅 I'm just surprised that this got deployed as-is, it doesn't seem ready for prime time.
It's not just about lack of scheme handlers. In my case, Element was being successfully launched... on the wrong profile, giving this nonsensical error message. Same thing could happen with "portable" installations, sandboxed browsers etc. on any platform.
Also, the "device" shows up on the list even when the token never reached the app.
@dos @bart No worries, we're used to people ranting about Element at this point :D
The whole next-gen auth project was a very long-running one (4+ years) with many moving parts, and still a bunch of things to solve. Sounds like the Device Code Grant would fix it for you in this case.
I was not aware of the multiple 'profile' in Element Desktop being a thing; it should work really though according to one of my colleague working on ED. Could you check if there is an existing issue about the callback not working with multiple profiles, and if there isn't any, open one? That would help move things forward and have it under the right team radar :)