MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC

[hughns]

Rendered

Dependencies/sub-proposals:

• [WIP] MSC2964: Usage of OAuth 2.0 authorization code grant and refresh token grant #2964
• MSC2965: OIDC Provider discovery #2965
• [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966
• [WIP] MSC2967: OIDC API scopes #2967
• MSC3824: OIDC aware clients #3824

[MTRNord]

Nit: imho this is positive as it makes sure that the community agrees on best practices. This is how matrix spec works and imho should not get bypassed.

[turt2live]

I'd disagree: The spec is meant to define a communications protocol. While part of that communications protocol needs to include authentication, it should not be such a massive part of the implementation complexity. With the current team's availability I don't believe we'd ever properly catch up with security best practices for authentication. As a result, it's important that we don't become a communications+authentication protocol and instead "outsource" the authentication as much as possible to a protocol which can handle security best practices in a more timely manner. We believe the best approach for this is OIDC at the moment.

[hughns]

I think the point I was trying to get across in the 👎 was: As an auth protocol, Matrix is way behind OIDC. To catch-up and keep pace with the state of art this (single) MSC proposes that Matrix adopts OIDC instead.

[compgeniuses]

you are right, outsourcing the authentication component to a more advanced and dedicated provider, makes sense, so that matrix can move with speed to be a communication platform.

[MTRNord]

How is this different from any other SSO unless we would have a central server? With OIDC you end up with multiple pages still as matrix is not a central service

[sandhose]

It is different in the sense that we would be building trust between the user and their homeserver. Right now, the user does not interact with their HS much. Here, it would make it easier for user to understand that their account is living on their HS, and therefore they should only ever enter their account credentials on a web page controlled by their homeserver, not some random web application which claims to be a secure Matrix client.

[deepbluev7]

I don't think this provides any actual protection though, unless you whitelist specific apps to be trusted.

As long as the login page has a somewhat standard layout, unless I am missing something, it is trivial for a native client to replace the login page behind the scenes for the user or just inject code into the website to steal credentials.

You can only somewhat prevent that by not using a password at all and instead requiring a second device to authenticate the login or 2FA, which is orthogonal to OIDC.

Also, it's a bad idea to use an untrusted client for E2EE anyway. Under those circumstances you should rather be distrustful of the server instead of your client.

[sandhose]

I don't think this provides any actual protection though, unless you whitelist specific apps to be trusted.

I'm having a hard time understanding what you mean here. What kind of whitelist are we talking about? The login page would usually be shown in the default browser, even for native apps. Sure, showing a web view embedded in your native app is tempting (and completely possible), but you usually avoid that because:

• you would not share the cookie jar with the browser, meaning that your user would have to log in again even though they might already be logged in their browser
• you would not access whatever passsword manager the system has easily. If you leverage the default browser, the login page would have the right origin associated with the login page, which means it would suggest the right entries instead of having the user manually look for the right entry
• the user usually has pretty good trust in their default browser, and know where to look for to know on which origin/website they are on. Sure, it's not fool proof, and phishing attacks are possible, but it is still probably better

As long as the login page has a somewhat standard layout, unless I am missing something, it is trivial for a native client to replace the login page behind the scenes for the user or just inject code into the website to steal credentials.

If you do the login in an embedded web view, sure, but not in the system browser. Also note that on both Android and iOS, the system has APIs to open 'browser' views without changing apps. I recommend checking out the GIFs about that on https://areweoidcyet.com/

You can only somewhat prevent that by not using a password at all and instead requiring a second device to authenticate the login or 2FA, which is orthogonal to OIDC.

What do you mean by 'orthogonal'? Getting beyond passwords is very much one goal that would be easier to achieve with OIDC: you can imagine any kind of credentials (TOTP based 2FA, WebAuthN based login/2FA, or even a one-time-code sent via a Matrix DM) without having to add it to the spec. Implement that on your OIDC server, and you have support in every single Matrix client (assuming we manage to migrate those clients to OIDC) without modifying them

Also, it's a bad idea to use an untrusted client for E2EE anyway. Under those circumstances you should rather be distrustful of the server instead of your client.

That does not change, your server still doesn't have your keys. What changes though, is that a bad client can't take over your account anymore: it can't change your password, logout from other sessions or even deactivate your account.

[deepbluev7]

I'm having a hard time understanding what you mean here. What kind of whitelist are we talking about? The login page would usually be shown in the default browser, even for native apps. Sure, showing a web view embedded in your native app is tempting (and completely possible), but you usually avoid that because:

I am saying that for exactly those reasons it isn't really a security benefit. The difference between a webview and a browser is not clear to the user and just making the user only trust the webpage doesn't mean that it isn't still fairly trivial to spoof it.

If you do the login in an embedded web view, sure, but not in the system browser. Also note that on both Android and iOS, the system has APIs to open 'browser' views without changing apps. I recommend checking out the GIFs about that on https://areweoidcyet.com/

That doesn't prevent usage of a webview so users only trusting specific websites is not a significant benefit. Yes, a trustworthy app will probably use a browser, but the difference between that and a webview is not obvious to a user so you don't solve the problem usually associated with "entering the password into random websites".

What do you mean by 'orthogonal'?

I am saying that the problem of entering your into specific websites is not solved by using a homeserver provided website, it is solved by authenticating using an already trusted device that provides only the information necessary, which can be 2FA, etc. The other bullet point is completely valid that OIDC already specifies ways to do that, which makes implementation of that easier. But the specific bullet point about training people not to enter their passwords into native apps is not useful as long as any malicious app can use a webview and attack the password/auth that way.

That does not change, your server still doesn't have your keys. What changes though, is that a bad client can't take over your account anymore: it can't change your password, logout from other sessions or even deactivate your account.

No, the server doesn't know my keys, but I need to trust the client anyway, so I don't see why it can't know my password, since it already handles data that is more important than my password. The argument that you shouldn't trust random clients is simply not applicable, if you want to read your E2EE messages in that client imo.

[mvgorcum]

It is different in the sense that we would be building trust between the user and their homeserver. Right now, the user does not interact with their HS much. Here, it would make it easier for user to understand that their account is living on their HS, and therefore they should only ever enter their account credentials on a web page controlled by their homeserver, not some random web application which claims to be a secure Matrix client.

I would argue that by implementing OIDC like this we're training users to expect to be sent to a random-ass website that looks vaguely official, and having them input their password there. This sounds like a phishers dream to me.

[kegsay]

No, the server doesn't know my keys, but I need to trust the client anyway, so I don't see why it can't know my password, since it already handles data that is more important than my password. The argument that you shouldn't trust random clients is simply not applicable, if you want to read your E2EE messages in that client imo.

We need to urgently clarify what the trust model is for E2EE clients. Some parts of this MSC are predicated on the fact that trusting the client = bad, trusting the server = good, but this is actually the opposite in an E2EE world, as you've explained. Due to this trust model, we are asserting things which negatively impact the ecosystem:

What do I do for my device which doesn’t have a web browser?

[...] Use a Resource Owner Password Credentials Grant (a.k.a. “password grant” or “direct grant”) where the username and password are entered into the client (i.e. the 3DS) and the client then sends the username and password to the OpenID Provider to get an access token.

It is important to note that the second option (Resource Owner Password Credentials Grant) is considered insecure by the OAuth 2.0 Security Best Current Practice guide. As such, it is expected that the presence of this capability in an OpenID Provider can not be relied on. For example, we don’t expect that matrix.org will support this flow.

So we are asserting that matrix.org won't support clients which don't have a web browser in an OIDC world, because we don't want to enable password grants because we trust the server more than the client. The best practice guideline states:

The resource owner password credentials grant MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.

But for our ecosystem this is inevitable because we support E2EE so the keys only exist on the client so we must trust the client. In fact, we go even further because we need to handle attacks where the server maliciously controls our account, so we need to protect everything worth protecting behind strong crypto (e.g cross-signing) rather than trusting the server.

[MTRNord]

I disagree. It is harder for apps and native (as in QT and others) to implement. The user has to be redirected either to a browser where then the app needs to either handle a custom proto or a webserver for the callback, or they need a webview which usually involves compiling a full chromium suite which extremely increases compile times and makes you have to do way more regular updating of the client due to the rapid amount of security issues within chromium. It overall adds a lot of complexity to the update process and especially makes the experience worse for small client devs imho.

[sandhose]

I think the main point here is the abondance of off-the-shelf libraries to handle OAuth/OIDC, which helps with implementation for clients. For example, QT has an official module to handle OAuth2/OIDC logins that you might want to check out: https://doc.qt.io/qt-6/qtnetworkauth-index.html
Your point on custom proto or web server for the callback is valid (it's handled by the QT module with a local web server), although it is already the case with m.login.sso, which is used by a large portion of the user base (30% of Matrix.org, IIRC).

[deepbluev7]

Even with the OAuth module in Qt, the implementation is not really trivial and you usually need to test specifically against each OIDC provider to know if it is working properly, which is a lot more work than testing against 3 different homeservers. Google OAuth for example is very well known for changing in incompatible ways quite often (last time I tried it, it couldn't work with Google at all, but I assume they fixed that in the last few years). Here are a few of the potential pitfalls: https://appfluence.com/productivity/how-to-authenticate-qt-google-sso/

(The code in that example is about half as long as the UIA code in Nheko, so the implementation benefits don't seem to be particularly great considering that most of the UIA code is just putting stuff into a pretty UI so that it looks well integrated into the client.)

[sandhose]

Even with the OAuth module in Qt, the implementation is not really trivial and you usually need to test specifically against each OIDC provider to know if it is working properly, which is a lot more work than testing against 3 different homeservers.

There are indeed non-compliant 'OIDC' providers in the wild ('sign in with Apple' is a well-known example of that), as well as a lot of different scenarios to potentially support because of evolving best practices. OIDC is itself an effort to mitigate the lack of compatibility between OAuth2 servers and clients. There are also additional profiles which makes it even stricter for clients and servers for some use cases (the FAPI profiles is a good example of that). The OpenID foundation also provides a bunch of certification tools to help ensuring your server or client implementation is compliant.
In the Matrix spec, we want to be precise on what part of OIDC/OAuth 2.0 clients and servers HAVE to support to ensure compatibility between them.

That being said, the argument of having to test against 3 HS vs. having to test lots of OIDC servers is a practical one, not a spec one: if we had 40 HS implementations in the wild, would you test your client against all 40 of them? Probably only, because that's what the spec is for. The lack of diversity in homeserver implementations can be somewhat useful when implementing a client, but the spec should still be the source of truth when implementing a client or a server. That does not change with OIDC.

Moreover, we, for example, add semantics around dynamic client registration that are not present in any existing OIDC provider as far as I know, that will require specific modules to make those existing providers fully 'Matrix compliant', so don't expect users to be using any random off-the-shelf OIDC provider right away: they will probably use one of the few 'known compliant' provider, so you would probably still be in a situation where you only have to test a few implementations for your client.

Google OAuth for example is very well known for changing in incompatible ways quite often (last time I tried it, it couldn't work with Google at all, but I assume they fixed that in the last few years). Here are a few of the potential pitfalls: https://appfluence.com/productivity/how-to-authenticate-qt-google-sso/

That is a side effect of the best practices evolving over the years. OIDC/OAuth 2.0 did mature a lot since it was first introduced, so things that were considered 'secure enough' 6 years ago (in this case, using a web view instead of the system browser) are now deprecated. Having watched that space for a few years now, I think that we're in a state where modern OIDC is secure and stable enough to not have to worry about it changing too much.

(The code in that example is about half as long as the UIA code in Nheko, so the implementation benefits don't seem to be particularly great considering that most of the UIA code is just putting stuff into a pretty UI so that it looks well integrated into the client.)

I am curious about that claim. One thing to keep in mind, is that this is not only about logging in (which can be done with one HTTP request if you're using username+password), but all account management capabilities, like changing your password, 'forgot my password' flows, account registration (which can include a captcha, an email verification and terms of service acceptance), account deactivation, etc.

[deepbluev7]

In the Matrix spec, we want to be precise on what part of OIDC/OAuth 2.0 clients and servers HAVE to support to ensure compatibility between them.

I hope you mean, you want to restrict what OIDC/OAuth 2.0 flows are allowed to be advertized by clients? Because if something like "Sign in with Apple" is supported on even one public homeserver, clients usually have to support it no matter if it is compliant to the spec or not. So if "Sign in with Apple" is not compliant with OIDC, clients will have to implement workarounds for it.

That being said, the argument of having to test against 3 HS vs. having to test lots of OIDC servers is a practical one, not a spec one: if we had 40 HS implementations in the wild, would you test your client against all 40 of them? Probably only, because that's what the spec is for. The lack of diversity in homeserver implementations can be somewhat useful when implementing a client, but the spec should still be the source of truth when implementing a client or a server. That does not change with OIDC.

I think you will find very few client developers that agree with the statement, that you can follow the spec to implement a functioning Matrix client. You usually need to implement multiple MSCs as well as homeserver and client specific behaviour. For example Element iOS requires you send a thumbnail for a sticker to show it at all, Element Android sends wrong reply fallbacks for edits, Element Web starts the device verification flow in a long deprecated order, the spec didn't include edits for years, Synapse stored timestamps and powerlevels as strings in the past so you can't just parse them as integers if a user is still in an old room, construct sends room state in a weird order, conduit used to duplicate to_device messages for almost a year, dendrite used to store push timestamps in the wrong unit and for a long time one time and fallback keycounts were a mess. You absolutely need to test against as many options you can. I usually try all my test accounts on 4 different homeservers before a release as well as verification and calls between a few clients.

Yes, testing against 40 different homeserver implementations might not be feasible in the future, but the spec shouldn't define the minimum subset of OIDC clients should support, but rather the maximum API a client and server is allowed to support. Otherwise instead of simplifying authentication, this will make it much more complicated and fragile. I know that OIDC tries to make this standardized and interoperable, but in my experience we are still pretty far away from that (considering how much effort it is to integrate with all the different OIDC systems every time).

I am curious about that claim. One thing to keep in mind, is that this is not only about logging in (which can be done with one HTTP request if you're using username+password), but all account management capabilities, like changing your password, 'forgot my password' flows, account registration (which can include a captcha, an email verification and terms of service acceptance), account deactivation, etc.

The UIA part is implemented in a single file with about 300 lines: https://github.com/Nheko-Reborn/nheko/blob/master/src/ui/UIA.cpp

That is reused for every endpoint (apart from /login since that never switched to UIA) and drives a few hundred lines of dialogs (about 20 lines per stage type). Some pages opt in to integrate the dialogs better, which is additional UI, but I won't count that, since OIDC wouldn't allow that kind of integration. Similarly the implementation could be done in 100 lines if the fallbacks are used everywhere instead of custom dialogs. FluffyChat uses the same pattern, but notably the Element mobile clients do not (and they don't even implement the fallback properly...). Sure, Nheko doesn't implement "changing your password", but it does do registration (including registration tokens), terms of service, device deletion/renaming, device signing key uploads as a few of the endpoints that use UIA.

Adding the UIA handling to any such capability is just one line to pass the UIAHandler to the function (or rather, one extra argument). If any such things would still be handled client side instead of some webpage, they would be the same effort to implement presumably. (I know what UIA is and I have been working together with a few MSC authors to get rid of the "just send your password in plaintext option.)

[MTRNord]

Is this actually a thing SSO/OIDC solve? Wouldn't this be a thing WebAuthn solves?

Also who actually uses THE SAME account multiple times on the same device? Aren't you usually using the same client with DIFFERENT accounts? This usecase seems either fabricated to me or customer specific

[sandhose]

This will become in my opinion a pretty common use case, as we see other non-chat applications built on Matrix. On the same device you might be logged in your chat client, on your synapse-admin panel, in Cactus Comments, in Element Call, etc.

This does not change anything in terms of having multiple accounts on the same chat client.

Regarding WebAuthN, this is impossible to achieve with the current architecture, as WebAuthN credentials are bound the domain. If you create a WebAuthN credential from the chat.example.com origin, it won't be available on another.app.org. Here, since we're always requesting the credentials from the same origin (let's say, auth.matrix.org), we can bind WebAuthN credentials to that domain, and password managers will get a lot more useful.

[MTRNord]

I would prefer if the server does only know a hash of my password. This is usually the main issue with major security breaches. Matrix should do an best effort to prevent those.

[sandhose]

I'm not sure I understand your concern. Right now, even though it's not enforced by the spec it's the case, Synapse only saves password hashes in its database.

We would be in the same situation here: the server will most probably store the password as hashed, not in plain text

[mvgorcum]

We're just moving the problem from the synapse server to the auth server here, so we'll never be able to assume that the synapse server doesn't actually receive the password at some point, since the auth server and synapse server can still be on the same machine. We've added an extra step in our auth process that we can implement incorrectly. (ie: now we don't just need to make sure we do auth correctly, we also need to ensure that we do OIDC correctly). As such we're just creating a larger attack surface.

Conversely, if we keep auth as a part of a matrix server, the server can actually ensure it never learns the plaintext passwords, and as such allow this password to be reused for secure server side storage.

[MTRNord]

Please make sure to check if those are actually solved by this when doing it. There might be some around that OIDC does not fix but actually complicates, like the Concealed login MSC.

[sandhose]

That is a good point. We should spend some time identifying those MSCs sooner than later, and see for each MSC if either:

• it solves the problem solved by the MSC
• the tradeoffs are acceptable if it is conceptually orthogonal

[MTRNord]

Since now half a year went by: is there any update on which mscs are compatible and which aren't?

[hughns]

@MTRNord there is a start of a list at https://github.com/matrix-org/matrix-spec-proposals/blob/hughns/delegated-oidc-architecture/proposals/3861-delegated-oidc-architecture.md#alternatives

[turt2live]

just a mid-read review. Submitting before I forget about it

[turt2live]

I'd disagree: The spec is meant to define a communications protocol. While part of that communications protocol needs to include authentication, it should not be such a massive part of the implementation complexity. With the current team's availability I don't believe we'd ever properly catch up with security best practices for authentication. As a result, it's important that we don't become a communications+authentication protocol and instead "outsource" the authentication as much as possible to a protocol which can handle security best practices in a more timely manner. We believe the best approach for this is OIDC at the moment.

[MTRNord]

I am not sure if there is a better place, but:

How do we protect from ending up in the same situation as email, where big companies (like google/microsoft) end up using OIDC/OAuth2 purely to gatekeep the clients that are allowed to use? As far as I understand, matrix is supposed to be an open protocol where anyone is allowed to bring their own tools and software. So how do we make sure that this is still possible? I am aware of certain enterprise parts of matrix that want to restrict client usage, however imho this isn't something that should leak into spec.

The reasoning behind is that the Matrix Manifesto ( https://matrix.org/foundation/ ) clearly defines that we do want to be an open communication network and people shall have full control over their communication. If we end up however in a situation where we give HS admins a (too) easy way to restrict the clients that are usable we would break the goals of that manifesto at it's core, since then it's not open anymore for the users and Singular community managers can decide what tools to use with 0 protection for the users.

(edit: typos)

[MTRNord]

For additional source of my email reference, see the comment made by a thunderbird dev in https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat#OAuth2

Due to a defficiency in the OAuth2 spec, the client is usually required to send a client credential key, which in turn requires the client to be registered and approved by the email provider. Unfortunately, this not only allows email providers to block specific email clients (which is contrary to the idea of Open-Source), but also makes it impossible to support arbitrary OAuth2 servers. That's why Thunderbird is forced to hardcode the servers that it supports and the respecive client keys. That means that you cannot use OAuth2 for your own server. Only the servers listed on OAuth2Providers.jsm will work.

I am aware of the dynamic registration MSC for OIDC, but that only somewhat solves this, since there a provider still is able to refuse your client at any given time without explanation.

[hughns]

I've added references to the following MSCs that this proposal assumes are generally accepted:

• MSC3967: Do not require UIA when first uploading cross signing keys #3967
• MSC3970: Scope transaction IDs to devices #3970

[clokep]

From reviewing the Synapse implementation it seems that this MSC is missing information on how application services would register users. matrix-org/synapse#15582 keeps the old /register endpoint active for the m.login.application_service login type only.

This MSC needs to include some information IMO about how this interacts with application services.

[MTRNord]

I might be unable to find the right line in this huge amount of MSCs, but how does this new system translate users to mxids for events There needs to be some mapping right?

[tranquillity-codes]

Do I understand right that should this be merged into the spec, every client would have to support viewing or opening arbitrary websites with possibly complex CSS and JavaScript, making implementing a Matrix client essentially impossible on lightweight operating systems that lack support by any major web browser?

[programmerjake]

Do I understand right that should this be merged into the spec, every client would have to support viewing or opening arbitrary websites with possibly complex CSS and JavaScript, making implementing a Matrix client essentially impossible on lightweight operating systems that lack support by any major web browser?

maybe there's a way to use QR codes to transfer the necessary data so you can authenticate on some other system that supports web browsers