Support self-service account deactivation/deletion for users

[matrixbot]

This issue was originally created by @hughns at matrix-org/matrix-authentication-service#1876.

The self-service account UI should expose a UI to allow a user to delete their own account.

An admin should be able to disable this function if they choose. e.g. if deactivation is handled via an upstream IdP or some other means.

Open questions:

• how do we protect that flow? Send a confirmation by email? How does that work if there is no email attached to the account?
• do we set a grace period to prevent accidental deletions?
• do we send an account deletion notification? -> yes
• what about GDPR erasure?

Relevant design screens:

• Account deletion modal
• Account deletion button

[matrixbot]

This comment was originally posted by @hughns at matrix-org/matrix-authentication-service#1876 (comment).

@pmaier1 we need some product input on this, please.

Should the user be required to complete any additional verification step ahead of being able to delete their account? e.g. OTP via email and/or re-authenticate?

Do you want the re-auth requirements to be configurable by the server admin?

[matrixbot]

This comment was originally posted by @hughns at matrix-org/matrix-authentication-service#1876 (comment).

@jaywink please can you confirm if this is needed or not for the Element One migration? If not I will change the phase on the issue in the project board.

[matrixbot]

This comment was originally posted by @jaywink at matrix-org/matrix-authentication-service#1876 (comment).

@jaywink please can you confirm if this is needed or not for the Element One migration? If not I will change the phase on the issue in the project board.

@hughns This is not a blocker for EO, in fact we would actually want "An admin should be able to disable this function" to exist once MAS supports self-serve account deactivation.

[matrixbot]

This comment was originally posted by @americanrefugee at matrix-org/matrix-authentication-service#1876 (comment).

Here is the final design in Figma.

[sandhose]

Account backed by a social-login account are a bit of a problem if we want to reauth.

For a bit of context, without MAS, deactivation goes through an UIA-protected endpoint, exposed to client.
UIA means that the client needs to re-authenticate the user, which means either:

• re-enter their password, if they are password-backed
• re-do a SSO login, if they are SSO-backed

The thing is, the SSO-relogin itself doesn't do much, as most SSO will just… let the user go through with no reauthentication whatsoever.
What makes it okay, is that Synapse will show a page saying basically that the client wants to deactivate the account, and make the user click on a button to continue. This is explicit user consent that the client can't fake, as this is usually done through the system browser, and the client can't poke in there.

We can't rely on sending an email either, because the account doesn't necessarily have an email associated with them.

So that made me think of how other platform deal with social-login backed accounts and deactivation in general?
Turns out, some of them just… ask you to re-enter your email with a big warning prompt, like Notion:

I think it would be fine for us to adopt something like this for two reasons:

• it's not as sensitive as changing your account password, because there is no risk for loosing access to data to someone else
• this is not something a client could automate: this is in a UI a client doesn't display itself, but rather through the system browser

So I'm tempted to just transform the 'password' field in this dialog to something like 'please re-enter your MXID to confirm'

We could do this as a first implementation if we're alright with it. Ideally, we could have a grace period ('your account will be fully deleted in 24h') with an email notification, and a way to cancel this, but this would be significantly bigger to implement.

[erikjohnston]

The thing is, the SSO-relogin itself doesn't do much, as most SSO will just… let the user go through with no reauthentication whatsoever.

(Worth noting that some SSO flows allows specifying that the user should reauth BTW for exactly these cases, not sure how common support for that is though)

I think it would be fine for us to adopt something like this for two reasons

FWIW I think the attack we care about here is if someone gets access to a logged in session