Sharing account verification tokens to third parties

Question

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

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.