Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interesting idea! I did a quick look through your site and have a few issues:

1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection?

2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this?

3. Password reset emails come from @supertokens.io, which specifically raises phishing red flags when you get a password reset email from a domain that is not the one you're logging into. How would an integrator go about addressing this?



I second this! Please prioritize TOTP / U2F over social logins.

I might be off base here, but does anyone really leverage social logins anymore? Seems like it's the worst case scenario for auth in the case that a customer can no longer access the associated social account? Basically in every case you'd have to provide an antiquated flow for them to "re" sign-up with an email. I'm genuinely curious of the value add here, outside of using Sign In With Apple (since it parlays nicely into Apple Pay integrations).


From our conversations with developers, a surprisingly large number of their users use social login - even when the site provides alternatives. Many have categorically said that they cant use any solution without social login. And we've seen this generally be true across many use cases


I always use social logins if I can, much easier for me and no password to remember (even if I use password manager). I think most people (non techie) use social login.


> I might be off base here, but does anyone really leverage social logins anymore?

I'm sure there are on tiktok and other popular social apps.


1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD.

2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead. The issue with that is that there might be CSS clashes and to prevent that, we use shadow-root (HTML feature). On certain browsers, password managers do not work with a shadow-root. So we provide a config that the user can set to disable the use of shadow-root. This would solve the password manager problem, but the developer will have to make sure that CSS does not clash.

3. This behaviour is the default one to quickly get started. We provide callbacks on the backend SDK that devs can override to send a password reset email using their own email ID domain.


> On certain browsers, password managers do not work with a shadow-root.

Eek. Worse than that, certain browsers (e.g. IE11) don't support Shadow DOM at all! You may wish to consider widening your browser support.


Oh! Thanks for the heads up! I have created an issue about this on our github, referencing this comment.


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.


We've been working on a project similar as supertokens, but does not mess with password manager and with TOTP and WebauthN support (Yubikey is tested).

The project really needs a great frontend. Right now it's mostly just a an API with all these features. It's also MIT licensed:

https://github.com/curveball/a12n-server




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: