But seriously, no, obviously if you were to foolishly type your credentials for service A into a web form on web site B, now B has your credentials for A. Doesn't matter if that's a username and password, SMS code, TOTP. The only case where you aren't in serious trouble is WebAuthn (and its predecessor U2F) and that's because WebAuthn is bound to the actual DNS name of the relying party to defeat exactly this attack.
the problem is, Matrix has it's own login system, that does not support OAuth or offer any trust-less methods, such as login requests via a bot (how it's done in Telegram)
currently this is how all clients implement login to Matrix, be it Cactus comments or the beautiful Cinny client
Since the form asks for your homeserver, it seems like I'd be typing my password into a form controlled by you, which seems like a bad thing to train people to do?
EDIT: Also, "requires no backend to function" - but if I want to use this to give users access to their data in my backend, how can I do that securely? Do I get some sort of token from their Matrix homeserver that my backend can use to ensure that the client is authenticated as the user they claim to be? Or do I need to pass the username and password to my backend so that my backend can authenticate them with their homeserver?
Don't get me wrong: I love the idea and it's a cool project & great proof-of-concept. I think the current implementation is not secure enough for me to trust. It's possible that I'm mistaken and it actually is secure! But in that case I'd want to see some substantiated argument in the README, explaining how it works & why it's trustworthy.
matrix indeed does have it's own login UI, which you can embed in other applications (but it is quirky)
However, if the homeserver is using OIDC, the user credentials are handled entirely by the external OIDC provider and the client doesn't get them. But then you should be using OIDC directly and not "Sign in with Matrix."
Of course, untrusted clients can do all kinds of evil things after having authenticated. (And also clients still need the plaintext password at least client-side no matter what we do)
Are matrix devs seriously not aware of what OAuth is and does? That is ... concerning.
correct
after you sign in, you will get a token, which you can then use to authenticate against matrix home server
but this doesn’t work, because there is only one standard method of authentication, which is by sending username/password
A matrix bot could send the user a short-lived token they can paste to the site to authenticate. Optional QR for mobile.
No need for homeserver changes, changing protocols or touching any user credentials.
Since you’d rely on an existing matrix session, the bot could send the token e2ee, meaning after TOFU you could even protect against malicious homeserver operators.
You could also do the inverse, having the user send the token to the bot.
but it does not authenticate you against the homeserver and does not grant you the access token, meaning the application would not be able to access Matrix APIs on user's behalf
That’s exactly what you want to avoid.
The bot can still get things shared by the user like username, avatar, 3pids and pubkeys.
Can you give me a use-case that my proposed solution is insufficient for due to inability to impersonate the user to the Matrix homeserver?
Then I guess I'd have the backend send the user a link with an auth token after joining, that way at least no pasting needs to happen.
this project is less than a week old at the time, so only password-based method is implemented
and custom implementation: https://github.com/turt2live/matrix-oauth