-
Notifications
You must be signed in to change notification settings - Fork 380
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
MSC3824: OIDC aware clients #3824
base: main
Are you sure you want to change the base?
Conversation
This comment was marked as duplicate.
This comment was marked as duplicate.
(implementation nor the MSC have been sufficiently reviewed to remove the label - when someone on the SCT is comfortable with where things are at, they'll remove the label. Personally, I haven't gotten as far as deciding if I'm comfortable with it 😅) |
I think an important part of this would also be to be able to advertise what actions are available with each login method, e.g. {
"flows": [{
"type": "m.login.password",
"actions": ["login"],
}, {
"type": "m.login.sso",
"actions": ["login", "register"]
}]
} This would allow clients to properly display what's really available for each login method |
Co-authored-by: Richard van der Hoff <[email protected]>
Matrix Authentication Service support within it's compatibility layer is in matrix-org/matrix-authentication-service#221 |
The Web support has been merged so I think that this is ready for review. Android implementation is done too but not yet merged. |
Add an optional query parameter `action` to `GET /_matrix/client/v3/login/sso/redirect` and `GET /_matrix/client/v3/login/sso/redirect/{idpId}` with meaning: | ||
|
||
- `login` - the SSO redirect is for the purposes of signing an existing user in | ||
- `register` - the SSO redirect is for the purpose of registering a new user account |
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.
I think I'm missing something -- how would the client know whether it is logging in or registering?
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.
The user would have told the client if they already have a Matrix account or not.
For example, by clicking buttons labelled as such.
For an OIDC enabled homeserver to provide support for *OIDC aware* clients it would: | ||
|
||
- support OIDC delegation as per [MSC2964](https://github.com/matrix-org/matrix-spec-proposals/pull/2964) and others | ||
- provide a compatibility layer for `m.login.password` and `m.login.sso` that wraps on to OIDC |
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.
Is it defined how m.login.password
an be wrapped into OIDC? I guess doing the login itself?
- support OIDC delegation as per [MSC2964](https://github.com/matrix-org/matrix-spec-proposals/pull/2964) and others | ||
- provide a compatibility layer for `m.login.password` and `m.login.sso` that wraps on to OIDC | ||
- indicate that the `m.login.sso` is preferred by setting `delegated_oidc_compatibility` to `true` | ||
- make use of the `action` param on the SSO redirect endpoints |
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.
Make use of it to do what?
Co-authored-by: Patrick Cloke <[email protected]>
Rendered
Dependencies:
Servers
Clients