You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You will almost certainly need to break this story up into smaller parts before implementing it.
Background
Discovering homeserver support
Currently, Element Web is an "OIDC-aware" client, which means it has some slight alterations to its existing SSO login flow that make OIDC work a little better, but it doesn't take full advantage of OIDC.
Currently, to discover that a homeserver supports OIDC, we examine the list of available login flows (see Login.ts) and if we find a OIDC one masquerading as an SSO flow, we only display that.
Instead of this, before we ask the homeserver what flows it supports, we should check the .well-known info we have back from the homeserver, and if it contains the m.authentication section with the info we need as described in MSC2965, then use that to find what we need.
This means we must fetch another .well-known file from the issuer we got from the m.authentication server, and look inside that for the authorization_endpoint. Now, I (@andybalaam) think we have what we need to delegate directly to the authorization endpoint without asking the homeserver what auth flows it supports. This means we can jump directly to redirecting to that endpoint, somewhere near BasePlatform.ts startSingleSignOn.
The guiding MSC for this work is MSC2964, but the specifics you need here are in MSC2965.
This part corresponds to the first Requirement of OIDC Native clients - "Discovery of OP in /.well-known/matrix/client". Refer to the Client Implementation Guide for more info. It may also correspond to the second part - I'm not sure which Web UI is meant there - the login one or something else (e.g. signup or administration).
Summary
Support login via native OIDC in Element Web. Refer to https://areweoidcyet.com/client-implementation-guide/ for guidance. (You will need to find out what OIDC is before you can understand it.)
You will almost certainly need to break this story up into smaller parts before implementing it.
Background
Discovering homeserver support
Currently, Element Web is an "OIDC-aware" client, which means it has some slight alterations to its existing SSO login flow that make OIDC work a little better, but it doesn't take full advantage of OIDC.
Currently, to discover that a homeserver supports OIDC, we examine the list of available login flows (see Login.ts) and if we find a OIDC one masquerading as an SSO flow, we only display that.
Instead of this, before we ask the homeserver what flows it supports, we should check the
.well-known
info we have back from the homeserver, and if it contains them.authentication
section with the info we need as described in MSC2965, then use that to find what we need.This means we must fetch another
.well-known
file from theissuer
we got from them.authentication
server, and look inside that for theauthorization_endpoint
. Now, I (@andybalaam) think we have what we need to delegate directly to the authorization endpoint without asking the homeserver what auth flows it supports. This means we can jump directly to redirecting to that endpoint, somewhere near BasePlatform.ts startSingleSignOn.The guiding MSC for this work is MSC2964, but the specifics you need here are in MSC2965.
I suspect the changes will be limited to Login.ts, BasePlatform.ts and nearby code. (But I am not certain -- @andybalaam)
This part corresponds to the first Requirement of OIDC Native clients - "Discovery of OP in /.well-known/matrix/client". Refer to the Client Implementation Guide for more info. It may also correspond to the second part - I'm not sure which Web UI is meant there - the login one or something else (e.g. signup or administration).
Dynamic and static client registration
We should support both dynamic and static client registration. See "Discovery and client registration" in https://areweoidcyet.com/client-implementation-guide/
Subtasks
The text was updated successfully, but these errors were encountered: