Skip to content
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

OIDC: Log in #25392

Closed
10 tasks done
andybalaam opened this issue May 17, 2023 · 0 comments
Closed
10 tasks done

OIDC: Log in #25392

andybalaam opened this issue May 17, 2023 · 0 comments

Comments

@andybalaam
Copy link
Contributor

andybalaam commented May 17, 2023

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 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.

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

  1. A-Authentication T-Enhancement Z-Labs
    kerryarchibald
  2. A-Authentication A-OIDC T-Enhancement Z-Labs
    kerryarchibald
  3. A-Authentication A-OIDC T-Enhancement Z-Labs
    kerryarchibald
  4. A-Authentication A-OIDC T-Enhancement Z-Labs
    kerryarchibald
  5. A-Authentication A-OIDC T-Enhancement Z-Labs
    kerryarchibald
  6. A-Authentication A-Login A-OIDC T-Enhancement
    kerryarchibald
  7. A-Authentication A-Login A-OIDC T-Enhancement
    kerryarchibald
  8. A-Authentication A-Login A-OIDC T-Enhancement
    kerryarchibald
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants