Sick of spending your time on auth, you decided to spend all your time on it?
If a thing annoys you it'll probably annoy a lot of people that are probably willing to pay to solve the problem.
Sick of spending time on Auth, we built an open source 'Stripe for Auth'
21–30 of 347 posts
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#221. 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?
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#23I got experience mainly with firebase and identity server. What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication? I’m far from an expert, but in past startups I’ve been scrambling to get SSO working for b2b saas, they bluntly said. Without sso we don’t want to use your service. So that was moved up our roadmap. E…
> What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication?
We plan on building a much more feature rich auth solution in a modular way - providing passwordless, 2fa, social, email / password login (exists already) + very secure session management using rotating refresh tokens (exists already). Being "modular" will enable users to only pick what they care about making it easy for them to implement. So we differentiate in terms of features and simplicity of use.
> Even something like e-mail verification is something I will not go without anymore. Makes sense! Next on our feature list
> Is this something you would use for your first 3000 customers? We aim that this would scale to a very large number of users - so you can implement it once, and then spend minimal time on it after.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#24We’re using Keycloak.org which is a great product, easy to use, a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect from modern user authentication and management system. You should check that out, user auth is indeed a solved problem.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#25I did find amusing that one of the talking point is to not have to trust AWS with your auth, but you offer a SaaS. (I haven't read details of the SaaS, maybe all data is still hosted outside of your service, but I would doubt it.) Not a problem, but a bit of a contradiction. OTOH, SaaS does alleviate some pain.
And yes, indeed. We will add the option where our SaaS will also write to your own DB as opposed to ours.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#26Edit: open source part = huge. Great work
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#27Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#28Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#29Congratulations on the launch! Innovation in the Auth* space is really necessary. How do you plan on differentiating from other open source solutions, such as https://github.com/ory/kratos or https://github.com/keycloak/keycloak ?
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#30Interesting 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 @su…
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.