I would absolutely consider this once email verification exists for new accounts. But not until then. It looks like a good feature set and yes, I would love to use a solution from someone who focuses on auth vs. rolling my own. I do think your documentation could be expanded. You have some examples of how to use it with Netlify, but I'd love to see example apps for other cloud providers as well (Heroku, in my case.)…
Thanks for the valuable suggestions! Email verification is next on our list of features. We plan on providing an "active" method which requires you to verify the email to sign up, and one "passive" method which reminds you to verify the email from time to time post sign up (similar to many social networking sites).
Sick of spending time on Auth, we built an open source 'Stripe for Auth'
31–40 of 347 posts
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#32Ooof.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#33Authentication is a solved problem; authorization is not. External authentication makes your system brittle, so I'm glad to see you can self-host SuperTokens for free. I've been working on Enterprise Access Control (EACL) in my spare time, an embedded Datalog-based library with a uniform declarative Clojure API that lets you write grant/deny ACL rules in the shape: Who, What, Why, When, Where & How that goes a little…
I agree with you that authorization is lacking a set of standards allowing interoperability. The only known practical one XACML, has not seen wide adoption. OPA through its design and API allow useful feature for Enterprise use cases for which Styra [2] (founder of OPA) is selling a solution based on those APIs.
Note: I am not affiliated with Styra in any way.
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#34Congratulations 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 ?
Thank you! I answered a similar comment which it seems like you've seen. Not sure I understood your response on that one. Why was the tone deplorable?
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#35I would absolutely consider this once email verification exists for new accounts. But not until then. It looks like a good feature set and yes, I would love to use a solution from someone who focuses on auth vs. rolling my own. I do think your documentation could be expanded. You have some examples of how to use it with Netlify, but I'd love to see example apps for other cloud providers as well (Heroku, in my case.)…
Thanks for the valuable suggestions! Email verification is next on our list of features. We plan on providing an "active" method which requires you to verify the email to sign up, and one "passive" method which reminds you to verify the email from time to time post sign up (similar to many social networking sites).
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#36We’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.
Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak: We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity. We provide far more flexibility and options on the frontend as well KeyCloak is a small part of the Redhat (and even les…
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#37Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#38I 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…
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#39I'm really happy to see a service like this and I wish you the best of successes. BUT :) If you're going to call yourself the "Stripe of X", please work on reaching the bar they've set for documentation.
Also, we agree - we have a lot to do before earn it (but also a fair comparison would be to Stripe's docs when they were new as opposed to today).
Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'
#40Authentication is a solved problem; authorization is not. External authentication makes your system brittle, so I'm glad to see you can self-host SuperTokens for free. I've been working on Enterprise Access Control (EACL) in my spare time, an embedded Datalog-based library with a uniform declarative Clojure API that lets you write grant/deny ACL rules in the shape: Who, What, Why, When, Where & How that goes a little…
This expression is idly thrown about nowadays. It implies that a solution exists and can't be further improved upon. Just because a solution exists, or is the current fashion, doesn't mean it's a 'solved problem'. Beer brewing is a 'solved problem'.. yet there are some brews you couldn't pay me to drink. Interesting problems are never fully solved, they are simply iterated on over and over. Payment processing was a 'solved problem' until Stripe came along. Assembly line manufacturing of cars was a 'solved problem' until Toyota showed Ford how it could be done better.