kratos
kratos copied to clipboard
Selfservice account deletion
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.
Could the following workaround be possible?
Open DELETE /identities/{id}
to the normal user and restrict user to only delete self.
Not really, this operation needs some checks, similar to the password update, where the session has to be recent enough.
@zepatrik Are there any plans for this feature?
Not really, all you can see here. But this is definitely an important issue.
How would I go about allowing users to delete their account without this feature?
You could use the admin API, and of course need some back-end wrapper around that as you should not expose it.
Alright thank you.
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.
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.)
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.
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.
Yes sure, like self registration it should be configurable as deactivated.
Is this going to be implemented any time soon? This is a necessary feature to deploy GDPR compliant applications using ory.
For the time being use the REST admin API to implement this flow! This is currently not on the immediate roadmap.
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.
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
Any progress on this? Whether it is a soft or hard delete should be up to the developer and ory should offer this flow.