Note that WebAuthn (the standardized replacement for U2F, you should not deploy U2F today) is deliberately designed to authenticate to the site you're actually visiting. It is possible (but not necessarily in all browsers) to override this and authenticate to an iframe for example to allow a third party to authenticate but this creates yet a further problem to deal with:
Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.
Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.
But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.
And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.
This would only be a threat if you're using the SaaS, right? If you self-host the user is still authenticating directly with your services, it's just that your services run a pre-made solution on the backend.
Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.
Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.
But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.
And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.