MSC4450: Identity Provider selection for User-Interactive Authentication with Legacy Single Sign-On

[reivilibre]

Rendered

[MadLittleMods]

As-is, this statement is confusing as m.login.sso also applies to login.

More clear:

Suggested change

	(Note that despite being called 'fallback', there is no other method for completing `m.login.sso`.)
	(Note that despite being called 'fallback', there is no other method for completing User-Interactive Authentication for the `m.login.sso` type.)

For my own reference, "User-Interactive Authentication" is separate from the login flow. User-Interactive Authentication is used to authorize a specific action (like when changing your password, deleting devices, etc) when you're already logged in.

[MadLittleMods]

the homeserver MAY either treat the parameter as not having been set

Feels like the homeserver should always error if it supports this parameter.

For homeservers that don't support this parameter, chances are it will be ignored though but that should just be noted as a client expectation (as it is already).

[MadLittleMods]

Given the homeserver is the one returning the session ID to be used in the User-Interactive Authentication flow, doesn't the homeserver have some idea about which SSO provider was used to login the user in the first place. And the homeserver could be using the same SSO provider for the fallback endpoint.

For my reference on how "User-Interactive Authentication" works:

1. Client tries to change password: POST /_matrix/client/v3/account/password with { "new_password": "newpass" } -> 401 { "flows": [{ "stages": ["m.login.sso"] }], "params": { ... }, "session": "xyz123" }
2. Client directs the user to /_matrix/client/v3/auth/m.login.sso/fallback/web?session=xyz123
3. User authorizes and the final HTML page has a few triggers to notify the opener about the flow being complete. For client apps that can't hook the postMessage notification, they usually just ask the user to press next when it's complete.
4. The client tries the same POST /_matrix/client/v3/account/password request but with { "new_password": "newpass", "auth": { "session": "xyz123" } } and the homeserver validates that the user ID of the requester matches the one in the session.

[MadLittleMods]

To answer my own question, Synapse already does this but users can be associated with multiple identity providers and we just arbitrarily select one. People want to be able to use whichever identity provider to authorize the action.

[MadLittleMods]

hmm, thinking about this more, this could also be solved by Synapse picking a more appropriate identity provider (the one you logged in with that particular the client) instead of picking an arbitrary identity provider used on your account.

[MadLittleMods]

How do we expect the client to know which idp_id to use from the list of identity_providers?

Especially in the face of:

Presenting a web UI for manual selection is not useful in this customer's situation as it would only confuse the user.

-- element-hq/synapse#19691

[MadLittleMods]

Reading element-hq/synapse#19691 a bit closer, in this case, it sounds like each client has a dedicated identity provider which is probably hard-coded.

(I'm unable to resolve this discussion)