continuwuation/continuwuity

Fork 10

feat: OIDC and external authentication providers #765

New issue

Open

opened 2025-04-16 19:27:12 +00:00 by nex · 4 comments

nex commented

2025-04-16 19:27:12 +00:00

Owner

Being able to delegate authentication to an external provider can be beneficial for reducing the number passwords people need to use, as well as allowing us to skip the anti-spam steps of email verification and captcha checking.

Also, something something MAS

nex added the

Enhancement

Matrix/Administration

Matrix/Client

Matrix/Auth

labels 2025-04-16 19:27:12 +00:00

Jade commented

2025-04-17 00:17:06 +00:00

Owner

It's probably worth skipping implementing legacy OIDC and doing this as we implement the new OAuth MSCs

nex referenced this issue

2025-04-30 14:24:01 +00:00

Implement MSC3861 support for OIDC authentication #209

nex commented

2025-04-30 14:24:41 +00:00

Author

Owner

see: #810

lafleur commented

2025-05-01 23:40:47 +00:00

I initially thought I would only implement it as a forwarder to the MAS server, but then I thought about some drawbacks :

each token check has to be forwarded to that server, creating latency (and attack surface)
that would somewhat bind continuwuity to MAS, which in turn seems to be developed along synapse

So I'm trying to focus on MSCs and OIDC compliance, aiming at a more robust feature. The OIDC authentication flow is provided by oxide-auth, which was a bit painful to get right, but is very comprehensive, and seems maintained.

Also, there are several web endpoints in the new ones provided by MSC3861, and there's going to be some user experience care needed at some point.

Indeed ! #810 aims at letting continuwuity act as an OIDC provider. My ambition is to add the ability to forward authentication to a standard external OIDC provider (in another PR), with kanidm as a testbed. But #810 is not done yet. I initially thought I would only implement it as a forwarder to the [MAS server](https://github.com/element-hq/matrix-authentication-service), but then I thought about some drawbacks : - each token check has to be forwarded to that server, creating latency (and attack surface) - that would somewhat bind continuwuity to MAS, which in turn seems to be developed along synapse So I'm trying to focus on MSCs and OIDC compliance, aiming at a more robust feature. The OIDC authentication flow is provided by [`oxide-auth`](https://docs.rs/oxide-auth), which was a bit painful to get right, but is very comprehensive, and seems maintained. Also, there are several web endpoints in the new ones provided by MSC3861, and there's going to be some user experience care needed at some point.

❤️ 1

lafleur commented

2025-05-01 23:45:02 +00:00

BTW, I had exposed my perspective in a (migrated) github issue

BTW, I had exposed my perspective in [a (migrated) github issue](https://forgejo.ellis.link/continuwuation/continuwuity/issues/209#issuecomment-14547)

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: continuwuation/continuwuity#765

No description provided.

Rows
Columns