Add ability to sign in to third party apps via synapse

[msuess]

Motivation

We are building a web app to manage synapse homeservers. We would like to be able to authenticate our users against their e-mail addresses and matrix passwords. Our current implementation looks like this:

1. display a form with inputs for email, password and homeserver domain
2. send a m.login.password request to homeserver with identifier.type set to m.id.thirdparty and identifier.medium set to email to receive an auth token
3. send the auth token to our backend
4. GET /_matrix/client/r0/account/3pid on the backend side using the auth token
5. check the returned email addresses against our own database and log in the user if a match was found

The problem with this approach is that it requires transferring the auth token to our servers and that we would be able issue any requests on behalf of the user using that token when we really just need to authenticate them using a 3pid for our own service.

Proposal

• add the ability to get a scoped access token that only allows access to read-only identification endpoints, or
• add the ability to acquire some signed payload containing the required identification info, or
• implement openid+oauth support in synapse

[clokep]

You might want the OpenID endpoint, but I'm unsure if it'll fit you use-case or not: https://matrix.org/docs/spec/server_server/latest#openid

[msuess]

We would need their email 3pid to be able to authenticate against our service.

[rxl881]

Probably already clear from the above, but for our use-case we only want users to be able to authenticate against their EMS hosted homeservers (not matrix.org or random (self-hosted) homeservers etc.)

[clokep]

It seems like the straightforward way of doing this might be to include the 3pids in the response to the openid endpoint. This would mean that a client could exchange their access token for an openid token and give it to a 3rd party, which could then exchange the openid token for a matrix ID and 3pid.

[callahad]

Some additional context from chatting with Rick this morning:

It is quite a pain point at the moment that our users have to have separate credentials for logging in to the EMS webapp than logging in to their EMS hosted matrix account, so it would be really helpful to unify them. [...] for now we're mainly just interested in unifying the two "EMS" sources of auth.

This is a very important improvement for the EMS team, but it's not a hair-on-fire / things-are-broken kind of task.

There are probably a bunch of ways in which we could solve this; we need to figure out what makes the most sense on the Synapse side. Marco is our point of contact for implementation on the EMS side.

[callahad]

@msuess If we implemented this, what should happen when the user's EMS server is down? Instead of authenticating against Synapse, would it make sense to put authentication into a separate SSO system that both Synapse and the management app authenticate against?

[msuess]

Good point @callahad. When the user's EMS homeserver is down it wouldn't work, which is a good way for our customers to shoot themselves in the foot, although they can always use their email address to login. OTOH, adding a separate SSO system would add a bunch of complexity. Where would that SSO system live? I guess it would be part of the user's EMS deployment? And how would we migrate existing deployments to the new SSO system?

@rxl881, do you have any thoughts on this?

[rxl881]

@callahad - as @msuess suggests if the user's Synapse is down the user could just authenticate with their username and password (we would probably need some way to show that the server is down in the UI and prompt them to do so).

An alternative (discussed with @jaywink and @Half-Shot previously) would be to have a Synapse specifically for EMS auth (e.g. just for authenticating against, rather than for processing messages), which could be used prior to setting up their own server, or potentially even in the event that is isn't accessible. This might be a better / simpler option than having an entirely separate system for SSO?

[clokep]

An alternative (discussed with @jaywink and @Half-Shot previously) would be to have a Synapse specifically for EMS auth (e.g. just for authenticating against, rather than for processing messages), which could be used prior to setting up their own server, or potentially even in the event that is isn't accessible. This might be a better / simpler option than having an entirely separate system for SSO?

I'm not sure I agree with this logic -- if you want a separate system to authenticate against than an SSO system should be used. That's what it is designed for. Running a separate synapse just to authenticate against makes little sense.

[clokep]

This sounds somewhat similar to #5323.

[Half-Shot]

Our need for this has passed, as we're going to use Keycloak as a SSO provider for EMS/Synapse.