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.