Earlier quoted context omitted.
You can login to any device on which you can login to your email. Most people can login to their from anywhere, on any device, via a browser. I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.
> I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important So basically this is not a solution for 99% of all services. Thanks for clarifying
Sick of spending time on Auth, we built an open source 'Stripe for Auth'
331–340 of 347 posts
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#332Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#333This is an idea that I briefly pursued for the same reasons you list, namely that it's a ubiquitous problem which needs to be solved repeatedly. But in a rough design sketch as to how I would create a generic solution, I made the auth service a proxy for the main app. So user data would be verified and decoded in the proxy, and the app could trust the passed token. This removes the need for a back end driver. I'm cur…
This is a complicated decision to have made and perhaps a blog post is needed for this. But here is an attempt to answer it: A complex enough app will require modifications to the auth flow. Most services achieve that via webhooks or by forcing devs to write code in their "dashboard". This code would then live outside the main codebase which is annoying. So we thought that if someone was making their own auth, they w…
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#334It's always great to see new companies trying to improve on this problem. I'm the CEO of FusionAuth and we've been working on our product for 6 years now. I can attest to the complexity and challenges that exist in this industry. Our belief is that no one should be building auth anymore. You should connect with Mike over at Gluu. He's a great guy and very supportive of the industry as a whole. I'm also happy to conne…
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#335Earlier quoted context omitted.
We're building email verification and social login at the moment and would love to have it ready in time for you. When do you plan to launch your product by?
Hoping to launch in January
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#336Hey Advait! Glad to see your work here man :) Will be watching the project closely over the next year. Having recently re-built authn + authz using Cognito (we evaluated Auth0 and building it ourselves as well) I can confidently agree that doing auth right is hard and complex. Especially once you get into social providers, keeping identities synced, MFA, etc. Excited to see where the project lands!
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#337Thanks for doing this. I've been waiting for this type of solution for a long time. Let's see how well it works!
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#338Is it there any support for a premade UI like firebase does? that's a great time saver for prototypes
The docs are here: https://supertokens.io/docs/emailpassword/common-customizati...
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#339Earlier quoted context omitted.
We have SDKs for other backend frameworks as well (like golang, laravel...). But those only have a session feature, and not login. Hope this provides some clarification.
Do you have a ETA for flask login support? I literally just rolled my own but I'll want to switch it over at some point.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#340Great initiative! As someone who has worked on Auth systems multiple times, I can so much relate to it. In fact, at one of the jobs I created something quite generic (SSO by SSO, multiple token types, multiple interfaces (including OAuth), multiple password backends, email domain specific verification methods, etc. Wanted to open source it, but then given it was related to security and we were not really a security c…