0

Now that Apple requires an account deletion function to be present in every app that has user accounts, I began implementing one for my app. However, I presume there may be security implications here.

I use JWT tokens for authentication in my app, and so the most obvious way is to have a POST endpoint, say /delete-account that requires usual JWT authentication.

Although this endpoint will be as secure as any other, the consequences of a malicious call to /delete-account with a stolen JWT are bigger compared to other endpoints.

What comes to mind first is, for example, to require the refresh token to be sent with this request too as an exception.

I was wondering if there's any industry standard way of handling this kind of requests?

mojuba
  • 11,842
  • 9
  • 51
  • 72

1 Answers1

0

What I ended up doing is:

/delete-account should adhere to the same security standards as /create-account: I send client_id, client_secret, plus for extra safety the refresh token is also present in the request. And of course the usual authentication with Authorization: Bearer <JWT>.

This improves the security provided that the client secret is kept in a storage different from where the JWT token is kept. If JWT is typically in the KeyChain, then client secret is e.g. hardcoded in the client's binary. A malicious actor may have access to one but not the other. If they have access to both then the client is seriously compromised and there's nothing else that can be done without increasing the complexity of the auth scheme (asking for a password or biometric ID, etc.)

Can't think of anything else at the moment, but I think in any case /delete-account deserves the extra steps since it's about destroying an account along with (potentially) the user generated content on your platform.

mojuba
  • 11,842
  • 9
  • 51
  • 72