This proposal sets out an alternative solution to the problem described in MSC1730: that of needing to redirect to an alternative homserver during login.
This proposal suggests a mechanism which is less general than that in MSC1730,
in that it works only with the m.login.sso
login flow for web-based
single-sign-on. However, it is simpler in some respects.
The m.login.sso
flow (which is defined by
MSC1721 is essentially as
follows:
-
Client sends
GET /_matrix/client/r0/login
to the server to establish the permitted flows.m.login.sso
is among those listed. -
The user selects a "log in with single-sign-on" option.
-
In web-based clients, the "log in with single-sign-on" option is a link to
/_matrix/client/r0/login/sso/redirect?redirectUrl=<redirect_url>
, where<redirect_url>
is a link back to the client which will be used later.In non-web-based clients, the client opens a web view on the above page, setting
<redirect_url>
to a URL which it can intercept. -
The server returns a redirect to the single-sign-on system, having arranged that when the single-sign-on completes, it will redirect back to an endpoint on the server with the authentication results.
-
The server then redirects back to the original
<redirect_url>
, with the addition of aloginToken
query parameter. -
The client then uses the
loginToken
as a parameter in a call toPOST /_matrix/client/r0/login
, withtype: m.login.token
. This returns the access token, as for a normal password login.
As well as returning a loginToken
at step 5 above, we could add a
homeserver
parameter. Clients would then add /_matrix/client/...
to this
URL to form valid C-S endpoints for step 6 and onwards.
A corollary is that we would need to extend the fallback login
mechanism
to add a second parameter to the window.onLogin
callback, giving the value of
the homeserver
field.