This is a brief sanity check for myself to confirm whether or not the premise of the title is a good idea or not.
Suppose we have an internal system for password reset or account verification. When a user performs an action, they are provided with a token identifying them through some external source (typically email). That token is then exchanged in some way to identify them and properly inform an API to perform some action.
Now, we have received some requests to allow for this token to be provided somewhere else programmatically instead of through that email. So instead of sending it via email, we would send it over HTTP to some pre-configured destination. That destination is managed by a third party that is not us and we have no visibility into what they are doing with said token, although, presumably, they would be simply forwarding that token to the customer for us using some medium we don't support (like snail-mail, or telephone call).
This raises some red flags because we're no longer interacting directly with the end-user, but I'm not sure if I'm being overly cautious.
Can anyone weigh in on things I should be aware of to support such a system? Any caveats or security holes that we would need to watch out for, or if this is just a terrible idea and I should be ashamed for even entertaining it.
The third party is a contracted-out development team responsible for building alternative methods for users to "verify" their account or reset their password.
For example, assuming we only have the ability to send these verification tokens via email, but our client using our service wants users to be able to send these verification tokens to users through Whatsapp.
The workflow would look something like this:
- user navigates to third-party.com and follows their onboarding flow.
- we create account and send verification token to https://api.third-party.com
- third-party captures the above request and sends the token to the user via whats app message
- user receives token via whatsapp, and enters token into third-party.com
- third-party.com sends an API request to us using that token, and we "verify" the account