This looks cool, I’d love to add it as a provider in https://useAuth.dev
Can’t wait to dig in
Sick of spending time on Auth, we built an open source 'Stripe for Auth'
61–70 of 347 posts
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#62Would love to see some code examples on the homepage. When I did find some code, using "recipe" and "recipeList" in your packages and examples was confusing. At first I thought the example code was a recipe app as the hello world. What exactly is a "recipe" in the context of supertokens?
I understand your confusion. You are right, we need to improve our explanation.
A recipe is essentially an auth experience. So auth with email + password (with forgot password & email verification) is a recipe.
Social login is another recipe. This recipe is independent to the one mentioned above.
There will also be a recipe that has both, social login and email password (like other auth providers).
The idea behind recipe is to allow devs to pick only what they want and not have to think about anything else - making development easier for them.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#63Interesting 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…
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:
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#64This 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 would want to have all their code in their backend API itself. The best way to allow that was to hide the auth server behind their API server (which is a proxy to the auth server for certain APIs like sign up / sign in etc..)
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#65I'm impressed and glad you chose a real Open Source license. I really hope you can make money off of this so it can remain free to use (and I think you can, judging by Auth0's customers)
Also, I assume you can add captchas as a custom theme. Could you add some sample code for that (and other user stories) in your docs/repos? In cases where somebody's got to implement something super quick, and there's a competitor who has really easy to follow docs, sometimes that alone can convert a customer.
The use cases we have for Cognito include: zero-trust authentication portals for services, enterprise SSO, customer portals for applications, session/user management. For Auth0, the same plus API management (including billing, authn+z, etc)
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#66We’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.
I cannot imagine building auth into a system now without using Keycloak.
It's a comprehensive platform for sure, which makes for some pretty intense concepts and documentation.
But once you lay your hands on a suitable tutorial it's dead easy to get running, and you'll never find yourself stuck when some PHB asks you about your password rotation policies, 2 factor auth, SAML, SSO etc. etc. Keycloak does everything you could ever want for auth.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#67For anyone else wondering: the frontend depends on NodeJS and the backend is Java. Ooof.
The SuperTokens microservice is in Java. The backend can be in anything (like nodejs) - for which we have an SDK that developers interact with.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#68For anyone else wondering: the frontend depends on NodeJS and the backend is Java. Ooof.
I came here to question exactly that. > Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon That's a very very odd combination.
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.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#69I know most people are not like this, but I don’t mind setting up auth “over and over”
It’s always a chance to read about what’s changed in the technologies/ideas you usually lean on for it. Apply that simplification that you wish you could have for your already launched application. Maybe you have a need to make your auth slightly more proprietary. If you churn out applications all the time yeah I get why this could all be seen as a waste of time.
I don’t say this to belittle your service at all, looks neat! Just throwing out an alternative viewpoint for the sake of it :)
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#70Is SAML Authentication on the roadmap?