OIDC: accept homeserver URL or domain in .well-known discovery functions

[kerryarchibald]

Part of element-hq/element-web#25472
Used matrix-org/matrix-react-sdk#11018

Previously, we only lookup .well-known during login/registration for homeserver urls without a domain (eg matrix.org) in an effort to validate them as server names.
As part of OIDC support discovery, we need to lookup the client .well-known for all homeservers to discover m.authentication config on the wk.
Extend findClientWellKnown functions to accept both domain and url homeservers.

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

✨ Features

• OIDC: accept homeserver URL or domain in .well-known discovery functions (#3426). Contributed by @kerryarchibald.

[robintown]

Looks reasonable to me!

[t3chguy]

The spec only defines the well-known lookup from a server name (really from a Matrix ID) - not from a Homeserver URL. They don't always match, especially when delegation isn't configured. This doesn't seem spec compliant? https://spec.matrix.org/v1.7/client-server-api/#well-known-uri

[richvdh]

especially when delegation isn't configured.

s/isn't/is/?

As an example, the "homeserver URL" for matrix.org is https://matrix-client.matrix.org, but https://matrix-client.matrix.org/.well-known/matrix/client doesn't exist.

[t3chguy]

s/isn't/is/?

What I meant is if m.org didn't set up the client well-known file, users would need to enter matrix-client.matrix.org which wouldn't match the server_name. But the symptom stands either way, if the user manually inputs matrix-client.matrix.org which is valid, this seems like the well-known won't be discovered and thus OIDC will not function?

[kerryarchibald]

The spec only defines the well-known lookup from a server name (really from a Matrix ID) - not from a Homeserver URL. They don't always match, especially when delegation isn't configured. This doesn't seem spec compliant? https://spec.matrix.org/v1.7/client-server-api/#well-known-uri

Sure, but when the server name is unavailable we can make an assumption and try our best to discover the configuration. I couldn't find a way to discover the server name from the homeserver url (apart from registering as a guest?)
FTR Hydrogen looks up .well-known like this already.

Being unable to discover OIDC config without .well-known is noted on the MSC with the alternative of a new dedicated endpoint suggested.

if the user manually inputs matrix-client.matrix.org which is valid, this seems like the well-known won't be discovered

This is true with the existing implementation.

[t3chguy]

This is true with the existing implementation.

This sounds like a major issue, what happens if well-known (and thus OIDC) isn't discovered? User is unable to authenticate? Sounds like an issue with the MSC.

Sure, but when the server name is unavailable we can make an assumption and try our best to discover the configuration. I couldn't find a way to discover the server name from the homeserver url (apart from registering as a guest?)

That's because a homeserver URL can actually correspond to multiple server_names (and thus well-knowns). At time of /login the server gives you a new URL to connect to, and its that server's server_name that matters here. The one corresponding to your account, not one guessed from a HS URL where there isn't a 1:1 mapping.