MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC #3861
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,132 @@ | ||
| # MSC3861: Matrix architecture change to delegate authentication via OIDC | ||
|
There was a problem hiding this comment. 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? There was a problem hiding this comment. I'm not sure I understand what you mean here. This proposal doesn't touch on events, and MXIDs are not really a concern throughout the flow. Could you clarify what you're asking here? |
||
|
|
||
| This MSC proposes a change to the architecture of Matrix with respect to how authentication works. | ||
|
|
||
| ## Existing architecture | ||
|
|
||
| Currently Matrix uses a custom authentication protocol baked in to the Client-Server API. | ||
|
|
||
| In a overly simplified form it looks a bit like this: | ||
|
|
||
|  | ||
|
|
||
| - Matrix Clients are required (and trusted) to show the UI for login and registration. | ||
| - Matrix Homeservers are responsible for authenticating users and issuing access tokens. | ||
|
|
||
| We've then added on things like: User-Interactive Auth which provides a standard for specifying an arbitrary sequence of steps including auth, T&C acceptance, CAPTCHA; password management; sessions management; and more. | ||
|
|
||
| The are issues with this current approach: | ||
|
|
||
| - 👎 Heavyweight for client and homeserver to implement and as a consequence many do not implement all capabilities | ||
| - e.g. Dendrite only does password auth | ||
| - 👎 Doesn't incorporate best security practices (particularly in case of SSO flow) | ||
| - 👎 Requires an MSC for every "new" auth capability such as 2FA and WebAuthn | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - 👎 We're training our users to enter their Matrix credentials in random web pages and native apps | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Matrix is not an authentication protocol | ||
|
|
||
| Quoting the [spec](https://spec.matrix.org/latest/#introduction-to-the-matrix-apis): | ||
|
|
||
| > Matrix is a set of open APIs for open-federated Instant Messaging (IM), Voice over IP (VoIP) and Internet of Things (IoT) communication, designed to create and support a new global real-time communication ecosystem. The intention is to provide an **open decentralised pubsub layer for the internet for securely persisting and publishing/subscribing JSON objects**. | ||
| So, fundamentally, Matrix does not set out to be a authentication protocol. | ||
|
|
||
| Yes, the ecosystem needs authentication to work, but it is not core to the mission. | ||
|
|
||
| ## Alternative architecture | ||
|
|
||
| The key concept of this proposal is the idea that the Matrix ecosystem would be better served by an architecture where authentication is decoupled from the Homeserver to some kind of authentication server. | ||
|
|
||
| That decoupling would be achieved by adopting an existing open authentication protocol rather than writing our own. | ||
|
|
||
| It would look something like this: | ||
|
|
||
|  | ||
|
|
||
| Some of the benefits of this are: | ||
|
|
||
| - 👍 Simpler for Homeservers and clients to implement | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - 👍 Benefits similar to SSO such as: | ||
| - logging into multiple clients on the same device without entering the credentials multiple times | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - having the credentials bound to the auth server domain instead of the client (for password managers and WebAuthn) | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - 👍 Benefit from larger existing community around a standard: | ||
| - Existing SDKs | ||
| - More battle testing and hardening | ||
| - 👍 Moves auth outside of the scope of Matrix spec | ||
| - ...allows the community to focus on what Matrix does best | ||
|
|
||
| It also allows the work of the Matrix community around auth to benefit other communities and users of the standard. | ||
|
|
||
| ## Adoption of OIDC as delegated protocol of choice | ||
|
|
||
| Specifically it is proposed that the OpenID Connect (OIDC) protocol is chosen to support the Matrix ecosystem. | ||
|
|
||
|  | ||
|
|
||
| There are six proposed action points: | ||
|
|
||
| 1. Accept the set of MSCs to enable delegation via OIDC. | ||
| 1. The Matrix.org Foundation join the [OpenID Foundation](https://openid.net/foundation/) as a non-profit member to support their work to build a robust and audited ecosystem for open authentication. | ||
| 1. Deprecate non-OIDC auth related API endpoints or capabilities in existing Matrix APIs. | ||
| 1. Provide migration support to the ecosystem. | ||
| 1. Close all existing MSCs relating to non-OIDC as `obsolete`. | ||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. That is a good point. We should spend some time identifying those MSCs sooner than later, and see for each MSC if either:
There was a problem hiding this comment. Since now half a year went by: is there any update on which mscs are compatible and which aren't? There was a problem hiding this comment. |
||
| 1. Remove the deprecated API endpoints/capabilities from the spec at an appropriate point in future. | ||
|
|
||
| Due to the complexity of this proposal it has been broken down into a number of constituent sub-proposals: | ||
|
|
||
|
|
||
| | Ref | Purpose | | ||
| | - | - | | ||
| | [MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964) | Describes how homeservers can delegate auth to an OpenID Provider | | ||
| | [MSC2965](https://github.com/matrix-org/matrix-doc/pull/2965) | Describes how participants in the Matrix ecosystem can discover the available capabilities of OIDC-enabled Homeservers and OpenID Providers | | ||
| | [MSC2966](https://github.com/matrix-org/matrix-doc/pull/2966) | Describes how OAuth 2.0 Dynamic Client Registration can be used to facilitate interoperability and openness of clients whilst promoting trust | | ||
| | [MSC2967](https://github.com/matrix-org/matrix-doc/pull/2967) | Defines the namespace for a set of API scopes that can can expanded in future to allow for finer grained permissioning | | ||
| | [MSC3824](https://github.com/matrix-org/matrix-doc/pull/3824) | Proposes some minor changes to the C-S API to allow Matrix clients that are not fully OIDC-native to work best with an OIDC enabled homeserver that has is serving a compatibility layer | | ||
|
|
||
| ## Potential issues | ||
|
There was a problem hiding this comment. 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 This MSC needs to include some information IMO about how this interacts with application services. |
||
|
|
||
| This proposal requires changes to all Clients, Homeservers, Bridges etc. This will take some time. | ||
|
|
||
| Furthermore, during a migration period it will be necessary to support both existing "legacy" auth as well as OIDC. | ||
|
|
||
| For existing Homeserver deployments we will need to work out migration paths and provide tools to facilitate the transition. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| The primary alternative is to continue to build out the auth capabilities within the Client-Server API. | ||
|
|
||
| For example, UIA (User-Interactive Auth) could be added to the `/login` endpoint and additional capabilities/flows added to UIA. | ||
|
|
||
| Examples of existing proposals include: | ||
|
|
||
| | Proposals | Comments | | ||
| | - | - | | ||
| | [MSC1998: Two-Factor Authentication Providers](https://github.com/matrix-org/matrix-spec-proposals/pull/1998)<br>[MSC2271: TOTP 2FA login](https://github.com/matrix-org/matrix-spec-proposals/pull/2271) | OP is free to implement MFA and many do. The [Matrix OIDC Playground](https://github.com/vector-im/oidc-playground) contains a Keycloak configured to demonstrate this | | ||
| | [MSC2000: Server-side password policies](https://github.com/matrix-org/matrix-spec-proposals/pull/2000) | Because the UI is served by the OP it is free to implement whatever password policies it sees fit | | ||
| | [MSC3105: Previewing UIA flows](https://github.com/matrix-org/matrix-spec-proposals/pull/3105)<br>[MSC3741: Revealing the useful login flows to clients after a soft logout](https://github.com/matrix-org/matrix-spec-proposals/pull/3741) | These become unnecessary as the burden to implement auth flows is moved away from the client to the OP | | ||
| | [MSC3262: aPAKE authentication](https://github.com/matrix-org/matrix-spec-proposals/pull/3262)<br>[MSC2957: Cryptographically Concealed Credentials](https://github.com/matrix-org/matrix-spec-proposals/pull/2957) | This is an interesting one as OIDC explicitly discourages a user from trusting their client with credentials. As such there is no existing flow for PAKEs. To achieve this in OIDC you would need to implement a custom grant in the Client and OP (perhaps an extension of the Resource Owner Password Credentials flow).| | ||
sandhose marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| | [MSC3782: Matrix public key login spec](https://github.com/matrix-org/matrix-spec-proposals/pull/3782) | Similar to above | | ||
| | [MSC3744: Support for flexible authentication](https://github.com/matrix-org/matrix-spec-proposals/pull/3744) | OIDC would instead be used as the pluggable layer for auth in Matrix| | ||
|
|
||
| ## Security considerations | ||
|
|
||
| Please refer to individual proposals. | ||
|
There was a problem hiding this comment. 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) There was a problem hiding this comment. For additional source of my email reference, see the comment made by a thunderbird dev in https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat#OAuth2
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. There was a problem hiding this comment. I'm not sure how to properly address this to be honest. MSC2966 outlines what the client must advertise, and what the homeserver should accept. If the HS doesn't accept a valid registration, I would argue that this HS is no longer Matrix-compliant on the C-S API side? This was always a possibility in the ecosystem: nothing prevented a homeserver to have an allow-list of valid redirect URLs for the m.login.sso flow. Note that the notes from Thunderbird are completely valid for email, but not for Matrix, as this 'many client, many homeservers' constraint means we have to have some sort of open client registration. Mastodon has something similar, Bluesky/ATProto as well… I'm not sure why it would not work for Matrix |
||
|
|
||
| ## Unstable prefix | ||
|
|
||
| Please refer to individual proposals. | ||
|
|
||
| ## Dependencies | ||
|
|
||
| The following MSCs are part of this proposal: | ||
|
|
||
| - [MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964) | ||
| - [MSC2965](https://github.com/matrix-org/matrix-doc/pull/2965) | ||
| - [MSC2966](https://github.com/matrix-org/matrix-doc/pull/2966) | ||
| - [MSC2967](https://github.com/matrix-org/matrix-doc/pull/2967) | ||
| - [MSC3824](https://github.com/matrix-org/matrix-doc/pull/3824) | ||
|
|
||
| The following MSCs are not directly part of this proposal but this proposal assumes that these are accepted: | ||
|
|
||
| - [MSC3970: Scope transaction IDs to devices](https://github.com/matrix-org/matrix-spec-proposals/pull/3970) | ||
| - [MSC3967: Do not require UIA when first uploading cross signing keys](https://github.com/matrix-org/matrix-spec-proposals/pull/3967) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reposting as a review to create a thread and allow replies, to work around GitHub limitations. Original comment will be replaced with a link to the review.
Reposting a comment we made in #matrix-auth:matrix.org here for better visibility
A preliminary analysis of the security impact in various threat models:
Default Model (Untrusted Server)
Security
The OIDC uses an untrusted party to provide security against another untrusted party. This means that in the default model, by itself, it is a zero net gain or loss.
Second, the OIDC enforces the use of browsers, massively increasing the attack surface. This makes it result in a net negative in the default model.
Let's also analyze restricted clients and privileged clients. We are failing to find a usecase. Let's list 3 of the permissions in the demo, plus a 4th one moderation events, and a 5th one, destructive client actions:
Client actions
View your existing messages
This is managed by the E2EE. In the default threat model, this is like the wolf protecting the sheep from another wolf. The wolf simply should not have access to the sheep. This is already the case.
Send messages on your behalf
In the default threat model, this once again is a net zero because a malicious party (the homeserver) can still do exactly that. Instead, incorporating client keys in the auth DAG of a room would prevent this (and we are working on that, though waiting on the new stateres)
See your profile
Same thing as before, net zero, in order to make the profile data secure against malicious parties, you should encrypt any important data and share the keys. Sort of like 4S.
Moderation actions
Same thing as before, net zero, in order to secure it, moderation events should be authenticated with signing keys of the moderator (another thing that we are working on)
Destructive client actions
Protecting the client's account would once again be better served by having a client (or possibly a user-hosted service, though one which might not be contactable by the homeserver; We work on this in our to-be-drafted Tor proposal) save its state + using pubkeys instead of MXIDs, but roaming accounts is far, far away, so OIDC is an actually realistic solution for this in the short term, as far as we can see. Though for an actually good UX, a secure embedded browser or popup should be utilized, preferably a solution that involves more secure blobs ran in a trusted environment, instead of a full-on browser. Though since platforms lack this, it's more realistic to fall back on a browser, and have the more secure trusted environment stuff experimental.
Phishing
On the web, using a centralized HS-controlled domain for the HS is more resistant to phishing of the actual credentials. This is good, since malicious phishing clients are much, MUCH easier to operate than malicious homeservers or malicious native apps.
For native apps, if you install a native app it can already hook itself into the system and keylog you. But it's more likely to be vetted, so, for native apps, this doesn't really do anything (we think eg. Flatpak)
UX
For browser clients, the argument with the password manager scoping is good. We agree, the UX on the web there is superior.
For native clients, it feels incredibly wonky to manage two windows for one application. Thus, an embedded secure surface that's reparented into the surface is necessary (on Wayland). On Android, this is trickier, as they offer no such thing as we can tell.
Selfhosted model (Trusted server)
It's pretty clearly a huge improvement. Unfortunately most users don't selfhost, and many of those that do are likely to vet their clients (we do that, so we don't have a use). Though there are certainly HS admins out there that would benefit from this for their instances that are trusted (take, a friend group or a corporate environment)
We'll analyze the rest later, gonna just leave this here for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one part you haven't considered is unencrypted public channels e.g. because they're bridged to IRC or similar, there trusting the server is required, so you can't just say everything depends on end-to-end encryption and ignore any other attack vectors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what manner have we not considered them ? Exactly what changes ?
If you have any concerns with our assessment write them down, please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that basically there should be a different threat model for public unencrypted rooms with an IRC bridge where the server is trusted to not post stuff you didn't actually say (since IRC has a trusted server model afaik).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The authenticity of bridged users is a responsibility of the given bridge.
Public unencrypted rooms should still offer ways of ensuring message integrity (such as integrating client-managed keys into the room DAG for events that have to be intact), though it shouldn't be necessary to not compromise deniability even more than it already is.
Public unencrypted rooms are not impacted by the ability to read messages because anything can read messages already. As for writing messages, this can be handled by introducing an event type a client can send to require the usage of client keys for sending events in a room, this cryptographically prevents unauthenticated clients from writing into the room without permission (possibly with the ability to sign an event that retracts the requirement)