As I said in a comment - we don't do review of arbitrary third-party API's here. But given that the site claims to provide an API for easy integration of password-less logins I find it worth to take a closer look.
The problem is that there are no real technical information on this site on how this works. I've tried there small demo and found that it works be either the client send them a mail with a specific recipient and they log you once they receive this mail - or that the client provided them with an email and they send a link and after clicking on the link the user is logged in. This means probably that all what is needed is for someone to have access to your mail account - and maybe even the possibility to fake sending mails from your account (which is easy) is sufficient. For more on this topic read
Passwordless login over email - security considerations.
But there are even more warning signs. If you look at the prominently featured documentation how simple an integration is you will notice that
- It recommends to include a script from a third party site which you don't control. This script has essentially full control over the site in the browser, i.e. can extract information from it, change information, submit information with the origin of your site etc. See Should I be worried of tracking domains on a banking website? for more information.
- It recommends to include the script as insecure
http:// and not secure
https://. This means that the transport of the script is not protected against man in the middle attacks which can manipulate the contents of the script and thus essentially have full control over your site display in the browser. Fortunately, if your site itself uses
https:// (recommended) such insecurely included third party scripts will not work at all. But this also means that if you just follow the documentation the integration of the service will either be insecure or it will fail completely. And it gives some idea of the (missing) security mindset of the developers of this service.
- But third party scripts can actually be included in a secure way. subresource integrity lets you specify the hash for the expected script. And it is actually supported by most major browsers. Of course, with subresource integrity the third party cannot just make changes to the script - but this is probably exact the thing you are trying to avoid.
Another red flags are there security claims. To cite from the FAQ part of their site:
Is Swoop secure?
Swoop uses state-of-the-art 2,048-bit encryption to
authenticate your user. But what does that even mean? Well, if a
hacker got started 13.7 billion years ago (at the start of the Big
Bang), then he would still only be .00000213% of the way done. That’s
how secure it is.
And this is just bullshit and playing with big numbers. The only state-of-the-art 2048 bit encryption they could mean is RSA - the others use far fewer bits (like 256) since these are sufficient. And you only need 2048 bits with RSA since RSA is not as good as the other algorithms.
Apart from that it is not clear what gets encrypted here in the first place. It cannot be the mails which are sent for authentication because swoopnow has no control over how the mail gets delivered. See How (in)secure is POP/IMAP/SMTP and How secure is e-mail landscape right now?.
- they can collect and misuse the mail addresses of your customers
- the documentation for integration they provide results either in an insecure integration or one which does not work
- the make silly security claims instead of providing any real design information