MSC3744: Support for flexible authentication #3744
Conversation
Signed-off-by: Charles Wright <cvwright@futo.org>
turt2live
changed the title
turt2live
added
client-server
|
@cvwright please don't forget to sign off on your changes, and update the file name/location for your MSC number: 3744 |
proposals/3744-flexible-auth.md
Outdated
| ### New `GET /register` endpoint | ||
| The client also needs some way to know which authenticators are supported | ||
| by the server. | ||
| The proposed approach is to add a new `GET` method for `/register`, similar | ||
| to what is already done for `/login`. | ||
| The server responds with a list of the supported authentication types. | ||
|
|
||
| `GET /register` | ||
|
|
||
| ```json | ||
| { | ||
| "auth_types": [ | ||
| "m.login.password", | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Why not just add auth_types to the existing way to discover registration flows? (sending an empty object as the body)
There was a problem hiding this comment.
That would make sense. The client already has to do the first empty request anyway, to start the UIA process. Not sure what I was thinking before -- probably too focused on looking at login. Anyway, I can push an update with the suggested change.
There was a problem hiding this comment.
On second thought, I'm not sure how this would work. The first empty POST to /register should be intercepted by the UIA layer, right?
My understanding was that the actual endpoint handler wouldn't see a POST request until the client had satisfied all of the required stages of the UIA.
Signed-off-by: Charles Wright <cvwright@futo.org>
Signed-off-by: Charles Wright <cvwright@futo.org>
| **OpenID Connect.** | ||
| Rather than implementing more authentication types in the Matrix CS | ||
| API, Matrix could switch to using OpenID Connect. | ||
| Then all the complexity of handling different authentication mechanisms | ||
| is pushed out into the OIDC Provider. | ||
|
|
||
| OIDC might be the proper direction to go in the long run. | ||
| But for now, as a stop-gap measure, we can build better security using | ||
| the building blocks that we have in the existing CS API. | ||
| Also, some installations may not want to depend on a third party OIDC | ||
| Provider for a foundational thing like authentication; this proposal | ||
| provides a way for such homeservers to achieve better security with no | ||
| third parties. |
There was a problem hiding this comment.
+1 to OIDC; the Matrix project see this as this as the correct direction (see matrix-org/matrix-spec#636).
I understand your desire to achieve improvements in a shorter timescale than OIDC can happen, but... given limited resources, I'm hesitant to spend much time on changes that we essentially plan to throw away in the next few months.
There was a problem hiding this comment.
I talked to Quentin about OIDC last week. It's very exciting stuff, and good to see Matrix building out capabilities in that direction.
However, IMO making OIDC the only supported option is premature at best, and it's an extreme measure for an open source project to be taking. Frankly it's a weird thing for a consumer chat app to be doing -- imagine DIscord or Signal or Telegram forcing you to hop through a web page to log in.
My own project requires a non-OIDC solution, so that's what I'm building. I'm trying to do it in a way that can be most useful to the rest of the community.
There was a problem hiding this comment.
How would OIDC work with something like Dendrite+Pinecone? Without forcing individual users to auth with centralized server(s) and without making the setup considerably more complicated for them than it would need to be?
It seems problematic for the case of making a client that connects over Tor or similar networks, too.
There was a problem hiding this comment.
There seems to be some assumption that federated homeservers in the foreseeable will look much like the current model, with the addition of p2p meaning either just that, or single-user-local-device where auth is either native or non-existant.
@Xnsamtr notes some ways that these assumptions don't necessarily hold. OIDC covers a lot of use-cases (possibly even the majority of users over the coming years) but opening up for alternatives is A Good Thing. I'd even speculate it'll become a necessity for Matrix to fulfill its goals. Identifying least-common denominators (which I see this as a good attempt at) means that people like @cvwright can solve their problems while being as compatible as they can with other implementations.
Rendered
This proposal describes changes to the Matrix client-server API to support a more flexible set of authentication mechanisms.