Comment by BrenBarn
2 days ago
> No more typing your password in every client you’d like to log in to.
So. . . how will we log in? This post is heavy on vague promises of greatness but light on concrete details of UX.
2 days ago
> No more typing your password in every client you’d like to log in to.
So. . . how will we log in? This post is heavy on vague promises of greatness but light on concrete details of UX.
If you use e.g., "Sign in with Google" today, you get redirected to your web browser, log in, and get redirected back to the client. This means you can use the saved passwords of your browser, and if already logged in there, you just have to click "continue" instead of logging in again.
With MAS, every login works like that. If you click "sign in", instead of getting redirected to Google, you get redirected to the website of your homeserver, where you can login and authenticate before being redirected back to the client.
The primary benefit of using a standard OIDC flow is that your authentication server can easily add support for passkeys, webauthn, TOTP or captchas, without having to wait for every single client to support these features.
While matrix.org uses MAS for this, providing the same login features as it used to, your organization might want to use Keycloak to connect their homeserver directly to LDAP.
The downside is that you need a full browser to authenticate this way.
> So. . . how will we log in?
I think you will log into your server, and then the server will offer you to give access to the client. The screenshot right below the line you quote seems to show exactly that.
I guess I can believe that, but it's unclear because there's nothing to tell me what that's a screenshot of. The icon in the screenshot is the Element icon, which is a client, so at first glance I figure it's a screenshot of Element. After reading your comment I can infer that it's actually something else (a website?) showing me the icon of the client that wants access. That makes sense, but it's not obvious just from the screenshot.
One reason I ask about this is I always wonder how it will work for someone writing their own client, perhaps a very basic client (or a bot). Any answer that involves "you will click on X" doesn't apply there. As long as there's a straightforward API based way, that's cool. And I assume there is one here. But my experience has been that such changes aimed at "greater security" often make things more cumbersome for small-time developers.
But we'll see. Certainly a smoother login (and logout!) experience for Matrix would be welcome so hopefully this will be a plus overall.
The blog mentions right at the start that it's based on OAuth 2.0/OIDC, similar to how you log in to your Google account in Thunderbird for example.
> I always wonder how it will work for someone writing their own client, perhaps a very basic client (or a bot).
For interactive clients, it'll be the standard OAuth 2.0 Authorization Code flow[1]. For non-interactive services they say in the proposal[2] that one uses the existing method but they will implement the standard OAuth 2.0 Client Credentials flow[3], which is effectively like a traditional username/password deal, though the "password" is not the account password.
[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...
[2]: https://github.com/matrix-org/matrix-spec-proposals/blob/002...
[3]: https://developer.okta.com/docs/concepts/oauth-openid/#clien...
Read the whole blog, and it directs you further for more details. But this blog does tell you they're moving to oidc. That means you will get all the non password flows oidc supports.
This is a reading comprehension problem more than a blog writing problem