Implement MSC3861 support for OIDC authentication

tcpipuk commented

2024-03-09 22:13:16 +00:00

(Migrated from github.com)

Many server admins prefer to centralise their authentication, so they can use a single system for login across all of their applications, then use one (ideally MFA) system for their users to login.

This simplifies user management, but also helps avoid requests for user management features, as password management and 3PID are handled by the OIDC provider instead of the Matrix server.

The overall MSC3861 exists for this, and has not yet been merged, but it's approaching maturity and MSC2964 specifies a comprehensive list of endpoints a server would require to handle OIDC authentication.

Many server admins prefer to centralise their authentication, so they can use a single system for login across all of their applications, then use one (ideally MFA) system for their users to login. This simplifies user management, but also helps avoid requests for user management features, as password management and 3PID are handled by the OIDC provider instead of the Matrix server. The overall [MSC3861](https://github.com/matrix-org/matrix-spec-proposals/pull/3861) exists for this, and has not yet been merged, but it's approaching maturity and [MSC2964](https://github.com/sandhose/matrix-doc/blob/msc/sandhose/oauth2-profile/proposals/2964-oauth2-profile.md) specifies a comprehensive list of endpoints a server would require to handle OIDC authentication.

👍 26 👀 2 ❤️ 7

zoujiaqing commented

2024-04-03 01:19:00 +00:00

(Migrated from github.com)

Good!
This feature is very good!

Good! This feature is very good!

🚀 3

zoujiaqing commented

2024-04-03 01:35:40 +00:00

(Migrated from github.com)

conduit support OIDC status:
https://gitlab.com/famedly/conduit/-/merge_requests/587

conduit support OIDC status: https://gitlab.com/famedly/conduit/-/merge_requests/587

wrenix commented

2024-07-01 08:25:10 +00:00

(Migrated from github.com)

Moved to here:
https://gitlab.com/famedly/conduit/-/merge_requests/676

Moved to here: https://gitlab.com/famedly/conduit/-/merge_requests/676

morguldir commented

2024-07-01 14:23:08 +00:00

(Migrated from github.com)

That's legacy SSO from my understanding, still interesting though

bartvdbraak commented

2024-11-15 02:00:36 +00:00

(Migrated from github.com)

I'd love to add this feature to my HS!

👍 4

lafleurdeboum commented

2025-03-13 15:58:27 +00:00

(Migrated from github.com)

Please correct me if I'm wrong :

we could support MSC3861 either by implementing all endpoints in MSC2964, or by supporting external authentication providers, such as keycloak, ory or matrix-authentication-service - ideally, any OAuth2 provider
the latter would require less work and prove more useful, as it would let conduwuit administrators integrate a matrix service behind an existing auth service
MSC3861 and related describe the clients' requested features in great details, but don't tell what it takes for a homeserver to use an authentication provider
MSC3861 complies with OAuth2, so RFC7662 is relevant to implement token in(tro)spection
matrix-authentication-service says it only supports Synapse, but if it complies with MSC3861 which in turn complies with OAuth2, then its homeserver-facing API should comply with some canonical URI
the bare minimum would be to implement the authentication server advertising (MSC2964), and token inspection (previous RFC) - that would at least let clients get an access token, refresh it, and change the user's password using the authentication server, and let users access their account with that token - MSC3861-ready clients should do the needed transactions directly with the auth provider

Please correct me if I'm wrong : - we could support MSC3861 either by implementing all endpoints in MSC2964, or by supporting external authentication providers, such as keycloak, [ory](https://www.ory.sh/docs/welcome) or [matrix-authentication-service](https://element-hq.github.io/matrix-authentication-service) - ideally, any OAuth2 provider - the latter would require less work and prove more useful, as it would let conduwuit administrators integrate a matrix service behind an existing auth service - MSC3861 and related describe the clients' requested features in great details, but don't tell what it takes for a homeserver to use an authentication provider - MSC3861 complies with OAuth2, so [RFC7662](https://datatracker.ietf.org/doc/html/rfc7662) is relevant to implement token in(tro)spection - matrix-authentication-service says it only supports Synapse, but if it complies with MSC3861 which in turn complies with OAuth2, then its homeserver-facing API should comply with some canonical URI - the bare minimum would be to implement the authentication server advertising (MSC2964), and token inspection (previous RFC) - that would at least let clients get an access token, refresh it, and change the user's password using the authentication server, and let users access their account with that token - MSC3861-ready clients should do the needed transactions directly with the auth provider

lafleurdeboum commented

2025-03-13 16:03:49 +00:00

(Migrated from github.com)

... Or perhaps OAuth2 doesn't prescribe canonical URIs for eg token introspection, and we'll have to use distinct APIs depending on what auth provider we support 😥

I skimmed through RFC6749 (oauth2) and RFC7662 (token introspection), I couldn't find no URI prescription.

~~So I guess auth providers are free to provide their own API endpoints.~~ I found in Synapse's MSC3861 implementation that OpenID Connect Discovery can be queried at an auth provider's /.well-known/openid-configuration to reveal its configuration.

... Or perhaps OAuth2 doesn't prescribe canonical URIs for eg token introspection, and we'll have to use distinct APIs depending on what auth provider we support 😥 I skimmed through [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) (oauth2) and [RFC7662](https://datatracker.ietf.org/doc/html/rfc7662) (token introspection), I couldn't find no URI prescription. ~So I guess auth providers are free to provide their own API endpoints.~ I found in [Synapse's MSC3861 implementation](https://github.com/element-hq/synapse/blob/ca290d325c762968e66842470475f05ae71a2aea/synapse/api/auth/msc3861_delegated.py#L181) that [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) can be queried at an auth provider's `/.well-known/openid-configuration` to reveal its configuration.

samip5 commented

2025-04-03 13:07:37 +00:00

(Migrated from github.com)

It seems that upstream conduit has an PR for SSO: https://gitlab.com/famedly/conduit/-/merge_requests/676

girlbossceo commented

2025-04-03 13:08:58 +00:00

(Migrated from github.com)

It has countless code flaws and problems, maintenance issues, and the author of the MR has left Conduit and has abandoned the MR. We will not be working off of this.

samip5 commented

2025-04-03 13:16:47 +00:00

(Migrated from github.com)

As I haven't really coded Rust (But Python, TypeScript and Go) at all, to me it doesn't appear that bad that we couldn't be working off it?

👎 2