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

1 Answer 1


Your requirement to provide verification codes through other channels than just email is quite sensible – but so is your concern about security. Unless you take extra steps, everyone who can intercept such a token can take over accounts. This holds for email as well as any other channel. In this case, routing verification codes through another company's service means that people who have access to the systems of that company could take over accounts. This could be malicious employees, but also attackers who have taken over the other company's systems. Of course, all of this applies to your organization as well.

So the question is what reasonable security measures can be implemented.

A lot of such reasonable measures will happen on an organizational or contractual level. For example, that other company might provide contractual guarantees to implement certain security measures, and might submit to regular audits. What would be appropriate depends on the sensitivity of these accounts: email, financial or health stuff usually but not necessarily more sensitive than an online game. This also depends on other regulatory requirements, e.g. GDPR.

You may also be able to implement some technical measures to increase security. However, in your scenario the other company mediates between you and the user so they could spoof any security measures if they wanted to. Notably, any verification tokens you create are entirely useless. The other company could just send the token back directly without performing verification. Equivalently, your API with them could simply contain a boolean isValid field, which would have the same level of security from your perspective: none.

Maybe, changing the viewpoint could constitute a solution: these are the other company's users, you merely implement white-labelled services for them. Then, you should be providing security guarantees to the other company, not the other way around. Whether this viewpoint is appropriate depends a lot on the specific services you provide.

Alternatively, strongly reconsider the flow where the third party performs the entire user interaction. If you can interact directly with the user but only outsource delivery of the token via the third party, that could significantly increase the security. For example, you could then ensure that the token was generated and consumed in the same browser session.

  • The alternative here for us would be to commit to the work this third-party is being asked to do in the first place. In the example, our client wants to be able to submit tokens via whatsapp, which we do not support. Adding whatsapp support would eliminate the need to open the process at all, but comes at a cost to us. In your opinion, would you suggest that the implementation costs to us would be less than the implementation for any requirement security or auditing work in order to support the third party? (obviously in the general sense, as a best-guess).
    – Chewy
    Commented May 4, 2021 at 20:51
  • @Chewy I have no idea because I have no context about your service. Partnering with a different company can be the best business decision – compliance work is probably easier than implementing this stuff yourself. But maybe the other company could merely do consulting for you, enabling you to run the Whatsapp integration on your systems.
    – amon
    Commented May 5, 2021 at 13:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .