-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC1731: Mechanism for redirecting to an alternative server during SSO login #1731
Conversation
|
||
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. |
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.
It's very important that clients don't blindly talk to the same HS as steps 1-3 else they will leak their login token. If we can make that impossible/difficult to do e.g. by setting a cookie on the target HS that would be preferable than just appending a query param, though admittedly harder to implement.
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.
...and would break backwards-compat :(
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.
Yup, we don't require anyone to support cookies in the C-S API right now.
I'm not sure how much of a concern it is if the login token gets leaked to the portal server: I'm pretty sure there are other, more reliable ways for an evil portal server administrator to get the user's credentials, given the portal server is sitting in the middle of the SSO flow.
The generality of MSC1730 is a lot more appealing to me. It gives servers a way to redirect clients to other servers without complicating the login flow for the user (as SSO is some amount more complex for the user than logging in via other methods). Not to mention MSC1730 is a lot easier to implement for clients than supporting SSO auth (assuming they didn't go the route of fallback). |
(I've updated the description of this MSC to give the reasons for proposing it) |
I am strongly inclined to agree with you. For my current project, this MSC has appeal since it is a trivial enhancement to what is there already, but in the general case of usefulness to the matrix ecosystem, MSC1730 seems more powerful, and makes this one redundant. |
@mscbot fcp cancel |
I think you mean: @mscbot fcp close |
@mscbot fcp close |
Team member @anoadragon453 has proposed to close this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
since #1730 has now completed its MSC, and nobody objected to this being closed, I'm assuming that people are happy with that. |
Rendered
Full disclosure for this MSC: the reason for me proposing it is that I have a project which requires users to log in via SAML to a portal server; based on the results of the SAML authentication, the user should automatically be logged into one of several homeservers.