kratos icon indicating copy to clipboard operation
kratos copied to clipboard

Selfservice account deletion

Open zepatrik opened this issue 4 years ago • 19 comments

Is your feature request related to a problem? Please describe.

Users have to be able to delete their account including all personal data (GDPR/... complaint).

Describe the solution you'd like

The new flow /self-service/flows/delete should allow users to delete all data associated with them. This hast to be at least CSRF protected, we have to check whether we want to (and are allowed to) reauthenticate a user (similar to password change).

Describe alternatives you've considered

Delete the internet.

zepatrik avatar Jul 22 '20 14:07 zepatrik

Could the following workaround be possible? Open DELETE /identities/{id} to the normal user and restrict user to only delete self.

wenqi73 avatar Feb 09 '22 10:02 wenqi73

Not really, this operation needs some checks, similar to the password update, where the session has to be recent enough.

zepatrik avatar Feb 09 '22 11:02 zepatrik

@zepatrik Are there any plans for this feature?

wenqi73 avatar Feb 22 '22 10:02 wenqi73

Not really, all you can see here. But this is definitely an important issue.

zepatrik avatar Feb 22 '22 10:02 zepatrik

How would I go about allowing users to delete their account without this feature?

Quasarman avatar Mar 22 '22 07:03 Quasarman

You could use the admin API, and of course need some back-end wrapper around that as you should not expose it.

zepatrik avatar Mar 22 '22 09:03 zepatrik

Alright thank you.

Quasarman avatar Mar 22 '22 09:03 Quasarman

Im just going over the documentation of this, and it seems like this could be accomplished by simply allowing the user to delete his own database record from within the authentication database only. Then once the user confirms the deletion, it could activate "hooks" (similar to the other ones available) that run before and after being deleted from the connected database.

This should allow the user to self-delete their identity and allow you to delete all other data related to that userID by using the webhook. Correct me if I'm wrong but I don't think this would be too hard to implement.

alantbarlow avatar Jul 26 '22 09:07 alantbarlow

While a self-service account deletion flow can be useful in some cases, in more complex setups it wouldn't suffice. Think of a distributed system where user data must be deleted or pseudonymised on multiple services / from multiple databases, not just Kratos. In those cases I would rather track and handle deletion requests outside of Kratos and handle the Kratos part via the admin API. Just throwing this in to say that in case this will be added in a future version, you should be able to disable this feature in the config.

(edit: I guess with a post hook this scenario could be covered as well.)

woylie avatar Sep 14 '22 09:09 woylie

I don't agree with @woylie. As the self creation of and identity, the self deletion of an entity should be handled by Kratos. There should be a hook, so other systems are notified about the deletion.

openscript avatar Nov 15 '22 08:11 openscript

I don't agree with @woylie. As the self creation of and identity, the self deletion of an entity should be handled by Kratos. There should be a hook, so other systems are notified about the deletion.

There are cases where self-service account deletion is undesired. Think of organization accounts, where user accounts are managed by an administrator.

woylie avatar Dec 03 '22 07:12 woylie

Yes sure, like self registration it should be configurable as deactivated.

openscript avatar Dec 03 '22 09:12 openscript

Is this going to be implemented any time soon? This is a necessary feature to deploy GDPR compliant applications using ory.

jonasbadstuebner avatar Jul 31 '23 14:07 jonasbadstuebner

For the time being use the REST admin API to implement this flow! This is currently not on the immediate roadmap.

aeneasr avatar Jul 31 '23 14:07 aeneasr

I think a self-service account deletion hardly suffers for GDPR compliance - you have to make sure data is cleared from your other systems as well in almost all cases. Thus our recommendation to implement your own endpoint to orchestrate actions, and call the Admin Delete endpoint. This way you can also choose to instead remove credentials and PII and keep a skeleton record as needed.

The self-service endpoint with Actions/Webhooks is a valid approach, too. As Aeneas mentions, this isn't on our near-term roadmap, though. If you'd like to contribute it, we'd be happy to review! Important is that any such functionality includes an explicit confirmation step with CSRF protection.

kmherrmann avatar Aug 01 '23 10:08 kmherrmann

Agree with @kmherrmann

It also probably needs to be a soft-delete that can be reverted for a given amount of time.

@kmherrmann we should probably add some documentation on what our recommendation is to build this on top of Ory

aeneasr avatar Aug 01 '23 10:08 aeneasr

Any progress on this? Whether it is a soft or hard delete should be up to the developer and ory should offer this flow.

janoschp avatar Apr 10 '24 10:04 janoschp