23 ms·

Sick of spending time on Auth, we built an open source 'Stripe for Auth'

• deleted 6y ago
  [deleted]
• codingdave 6y ago
  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.) Similarly for the react-auth documentation - the basic syntax of how to use it is a good start, but a full working app demonstrating its use with role-based authorizations would put it over the top to prove to me it could meet my needs.
  • rishabhpoddar 6y ago
    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).
    • oakst 6y ago
      For what it's worth I think email verification functionality would make me more keen to use a service like this!
      • advaitruia 6y ago
        Thats worth a lot! Would you mind sharing your email ID or ping me on: advait at supertokens [dot] io? I'll drop you an email as soon as we have it built
    • MH15 6y ago
      If email (or another mode of ) verification was added I'd be entirely on board for my next project (still in planning stage)
      • advaitruia 6y ago
        Thank you MH15! Its clearly top of the list for many people and it will be out before you need to build auth for your next project :)
    • leetrout 6y ago
      Do you have a uservoice page or issues on github where we could vote in support of a feature like this? I know "me too" comments might not be the most helpful but... this sounds like the only blocker for me too!
      • rishabhpoddar 6y ago
• pgt 6y ago
  Authentication 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 further than Role & Attribute. Link: https://github.com/theronic/eacl https://github.com/theronic/eacl Will do a Show HN when I fix all the bugs and get it fast enough. Tokens are an interesting approach to future-proof a young application against having to rebuild auth internally. I like your up-front Pricing Philosophy section.
  • p932 6y ago
    Worth to mention in the same area regarding authorization engine with APIs is OPA [1] which is relying on a Datalog inspired language: Rego. 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. [1] https://www.openpolicyagent.org https://www.openpolicyagent.org [2] https://www.styra.com/ https://www.styra.com/
  • j_m_b 6y ago
    > is a solved problem 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.
  • rkeene2 6y ago
    Cue Zed Shaw and "The ACL Is Dead"... I once worked on a project for flexible authorization called "SecureKit" which attempted to be a common criteria evaluated system for any kind of authorization. It quickly became apparent that it would pretty much have to be Turing complete to satisfy the general case. For example, some systems anyone can authenticate when a fire is occurring in some other areas, but normally only a certain set of people can have access to it.
• OJFord 6y ago
  Sick of spending your time on auth, you decided to spend all your time on it?
  • advaitruia 6y ago
    Haha we both did laugh at this one. I mean we were sick of doing it when we trying to build a product whos core value prop was different because auth was a distraction. We wanted to focus. Now that we're focussing ON auth, we are happy to do it cause it is the core product
  • Zealotux 6y ago
    If a thing annoys you it'll probably annoy a lot of people that are probably willing to pay to solve the problem.
    • advaitruia 6y ago
      Exactly
    • quickthrower2 6y ago
      It annoys me for sure and which it were simpler. What I found when integrating SAML is you have to work with whatever login code you already have which will build in assumptions across your app.
  • chaostheory 6y ago
    It's a pain point. It's always a good place to plant your flag.
• robertlagrant 6y ago
  This is a good idea. But I think a lot of your potential customers will struggle until you get OAuth2/SAML options, so they use you can offer premium auth options for their enterprise customers.
• Scotrix 6y ago
  We’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.
  • advaitruia 6y ago
    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 less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak). Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product. We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm. Finally - in general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one. I understand that this was not true for you. If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
    • korijn 6y ago
      How about keycloak-gatekeeper? Do you offer something similar?
    • rboyd 6y ago
      Is SuperTokens multitenant capable? My understanding is that keycloak suffers in a multitenant enviroment with a sufficiently high number of tenants.
• jsilence 6y ago
  On a technical level how does this compare to Mozilla Persona? Still sad that Persona died before it could gain some traction.
• pierrebai 6y ago
  I 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.
  • rishabhpoddar 6y ago
    Yea for those that do not trust a third party, we also offer a self hosted version in which all the data is stored in your own db.
  • advaitruia 6y ago
    A lot of companies would rather not send their user data to a 3rd party. For those, we offer the option of self hosting. The ones that you do not mind using a 3rd party, we also offer a SaaS version of our product. And yes, indeed. We will add the option where our SaaS will also write to your own DB as opposed to ours.
• ucarion 6y ago
  Is it fair to categorize the pitch here as "a simpler AWS Cognito"?
  • rishabhpoddar 6y ago
    Simpler and open source AWS Cognito.
  • mooreds 6y ago
    Don't forget that you can self host as well. That, for some use cases, is a simply killer feature.
• winkelwagen 6y ago
  I 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. Even something like e-mail verification is something I will not go without anymore. It’s mandatory in some countries. Honestly, next service that I will build will just be federated or magic email link if I can get away with it. From the frontpage I cannot understand yet what makes this easier then the options above. Is this something you would use for your first 3000 customers? Imagine being the cto, when would I feel confident going for something like supertoken? Also, it’s easy to ask questions like this, less so than building amazing things, so definitely Congratulations on the announcement!
  • rishabhpoddar 6y ago
    Thanks for your comment :) > 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.
  • redkoala 6y ago
    +1 for SAML 2.0 SSO support. I see this gap a lot in early SaaS products, it's a must if your product wants to onboard enterprise customers.
• defnotanai 6y ago
  Congratulations 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 https://github.com/ory/kratos or https://github.com/keycloak/keycloak https://github.com/keycloak/keycloak?
  • advaitruia 6y ago
    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?
    • defnotanai 6y ago
      I think you confused the threads :)
      • advaitruia 6y ago
        Oops, yes I did - haha. But I hope it answered your question? Also, when you say innovation is neccessary - what makes you say that? In the sense that do you have any specific pain points or innovation in mind?
• kkirsche 6y ago
  Sounds like this may pair with something like OSO for Python (osohq.com), thanks! Do you plan to directly support language specific client libraries or are you looking for community support of that work?
  • rishabhpoddar 6y ago
    Yea! Integrations with OSO makes sense! We do have plans to support language specific client libraries.
• munchbunny 6y ago
  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?
  • rishabhpoddar 6y ago
    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.
    • nicoburns 6y ago
      > 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.
      • rishabhpoddar 6y ago
        Oh! Thanks for the heads up! I have created an issue about this on our github, referencing this comment.
  • d33lio 6y ago
• Uptrenda 6y ago
  Thank you for working on such a horrible problem for developers. Looks amazing tbh. Will definitely try this out on a future project. Edit: open source part = huge. Great work
  • advaitruia 6y ago
    Thank you for your kind words - its really encouraging! Please do let us know when you are trying it out, we'd be happy to help and hear your feedback. You can join our discord (https://supertokens.io/discord https://supertokens.io/discord) or email me at advait at supertokens [dot] io
• funnyenough 6y ago
  Hi. Great work! We are using https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider and fairly happy with what it provides. How is it different? better than this popular open-source package?
• romtx 6y ago
  I'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.
  • advaitruia 6y ago
    Thank you so much! Appreciate it. 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).
• mike_d 6y ago
  For anyone else wondering: the frontend depends on NodeJS and the backend is Java. Ooof.
  • notretarded 6y ago
    What's wrong
  • afandian 6y ago
    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.
    • rishabhpoddar 6y ago
      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.
      • afandian 6y ago
        I was mostly confused that you would write something in Java that doesn't target Java. I'm writing stuff in Java (and Kotlin and Clojure) and, even though it looks cool, won't look too closely unless it supports Java.
        • ccleve 6y ago
          Yup. This. Give us an embedded library that will work with my Java app. JAX RS or or at least callable from within my JAX RS resource. Spring would be nice, too.
      • iamlolz 6y ago
        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.
• agentdrtran 6y ago
  How does this differ from something like Gluu?
• AlphaSite 6y ago
  How does this compare to something like Dex or Ory?
• snissn 6y ago
  feedback after 30s of looking into this - i'm not understanding what this is without email verification and social login
  • rishabhpoddar 6y ago
    For now, it's just email, password login, with forgot password flow and secure sessions. Email verification is next followed by social login :) Thanks for your feedback
• foreigner 6y ago
  I'm just in the process of setting up our Auth system now with cognito. It sure is painful! Looks like you guys have everything I need except social login.
  • advaitruia 6y ago
    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?
    • foreigner 6y ago
      Hoping to launch in January
      • advaitruia 6y ago
        Do you mind sharing your email ID or dropping me an email at advait at supertokens.io? We should have it ready by Jan (and hopefully in time for you)
• tacitusarc 6y ago
  This 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 curious about why you didn't choose this approach, and instead made the auth service callable from the app?
  • rishabhpoddar 6y ago
    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..)
    • tacitusarc 6y ago
      I suppose another upside is that you can do token validation in the app and not need to have proxy communication on every request.
• harrisonjackson 6y ago
  Would 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?
  • rishabhpoddar 6y ago
    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.
• tomc1985 6y ago
  Am I the only one weirded out by this page using the word "auth" exclusively? Like is this some kind of slang now?
  • mooreds 6y ago
    It's a nice shorthand for authorization, authentication and user management. I use it myself.
• Traubenfuchs 6y ago
  Does it have spring-boot integration?
• vmception 6y ago
  Reminds me of when I was working at the exact same kind of startup and then AWS Cognito got SAML support. I'm not exactly sure what that startup's business model actually was or what yours could be, they got acquihired and enough to pay back the VCs though. Auth really didn't get better since then?
  • advaitruia 6y ago
    We're bias but we obviously dont think so. Infact, we think its gotten more complicated over the years. Some of that complexity is for the right reasons but that isnt required for everyone and for all use cases
• Swizec 6y ago
  This looks cool, I’d love to add it as a provider in https://useAuth.dev https://useAuth.dev Can’t wait to dig in
• 0xbadcafebee 6y ago
  I'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)
  • advaitruia 6y ago
    Thank you for your encouragement! Yes, themes are customizable and anyone can contribute one. Adding captchas is a good idea and I've added it to the list of themes we have in mind. We'll build out a theme with captchas! Regarding sample code on how to do it, please let me revert, will have a look at how captchas work and if easily doable, will add it shortly. Your current use case for Cognito is beyond what we currently offer or plan to in the near future. However, we'd appreciate it if you follow along and consider SuperTokens for projects where we would be relevant.
• corytheboyd 6y ago
  I 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 :)
  • karakot 6y ago
    I never did it, what is a good guide to start? Thanks!
    • corytheboyd 6y ago
      Hey! I don’t have a guide on hand, maybe another commenter will see this and have some resources :) Honestly my experience is just collected from 10 years working with and around other web applications, and as such is a bit ephemeral. I’d say any guides out there on the topic will arm with you enough knowledge to get started, or even working with services like the subject of this post. You’ll see the pieces at play in action, and can learn from them.
    • tynorf 6y ago
      OWASP is a good resource for web security related topics. i.e. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...
  • chaostheory 6y ago
    I hate doing auth and commodity features like user admin along with SSO integration, and hooking it all up to both the front and back end. I'd rather be busy doing business related features.
    • corytheboyd 6y ago
• lukerohde 6y ago
  Is SAML Authentication on the roadmap?
  • rishabhpoddar 6y ago
    We plan on supporting it, but don't have a definite date for it as of yet.
• cleansy 6y ago
  Hi, just FYI, I saw that you are setting third party cookies without consent. While I generally don't like the flood of cookie banners, it's a legal requirement if you are accepting EU customers.
  • rishabhpoddar 6y ago
    Thanks for the heads up!! We will fix this ASAP.
• thaumasiotes 6y ago
  Considering the number of problems that arise when someone confuses "authentication" with "authorization", it makes me slightly queasy to see something claim a focus on "auth". :/
  • rishabhpoddar 6y ago
    Hahahaha. Fair enough. And it get's even worse when talking about sessions and tokens...
• InvOfSmallC 6y ago
  Will consider after go library introduced.
• arcturus17 6y ago
  I agree that auth is still a damn pain in the ass. My last two experiences have been with Firebase and Django, both with React front-ends. I think the state of JWT auth in Django with Rest Framework is dire. I've used the most popular packages (dj-rest-auth, which uses simple-jwt for JWT under the hood) and I've had to tweak way more than I would like to make it all work. I've been shocked to learn that this is not a solved problem in one of the world's most popular web frameworks, and I'd definitely consider using external auth in future projects. The Firebase experience on the other hand has been outstanding. The front-end SDK is great and so is the documentation. I had to implement SAML SSO for a massive corporate customer using Microsoft AD and was able pull it off in an afternoon without a hitch. The ability to add custom claims and the like is also great - the whole thing feels really feature-complete. But then there's the fact that I don't trust Google with my user data and that I fear that at any time they could start charging onerous amounts for the service, or worse. In both cases, the most painful bit however has been by far implementing the React front-end. Wiring the views, Redux async actions, etc. That's the part I wish I could get rid of. I see you provide some sort of front-end, but if you provided some sort of adjacent, standalone React library offering views and auth state management out of the box you'd surely get my attention - I'd possibly consider contributing code to it, too. Overall I think the whole idea sounds great and you may be on to something: in summary, I feel that Google can't be trusted, Auth0 looks eye-watering expensive, Keycloak looks a bit complicated for certain projects, and popular web frameworks like Django may not be as good at token auth as we would take for granted. I must be honest in that I wouldn't put your tech into production right now because I'm never a tech early-adopter, but I'll keep an eye on it, I'll seriously consider it for personal projects, and if it gets decent momentum in a few months I'll definitely consider extending it to client projects. Congratulations for launching - I really, really wish you the best of luck.
  • simonbarker87 6y ago
    Which SDK/package did you use for Firebase and React? There seem to be half a dozen and ReactFire the most dated?
    • arcturus17 6y ago
• inssein 6y ago
  > A great alternative to Auth0, Firebase Auth and AWS Cognito Can you elaborate a bit on how it's a great alternative, or what is different?
  • ryanmarsh 6y ago
    Indeed I’ve chosen each of the above for different projects. I’d really like to know what is different, specifically, about this product.
    • mooreds 6y ago
      They have a feature matrix here: https://supertokens.io/pricing https://supertokens.io/pricing It's at a pretty coarse level of detail, but maybe it will help?
  • advaitruia 6y ago
    1. Neither of these are open source. Also, the only option that can be run on premise 2. We take a modular approach to our architecture. This enables developers to choose only the features SuperTokens they need for their use case. They need not worry about complications associated with other features (eg: SSO and OAuth if you don’t need it) and this in turn makes it easier to implement and manage SuperTokens. This is not true for the others. Regardless of your use case, you likely have to worry about Oauth flows and integrating with a '3rd party' app. 3. Heavy focus on keeping documentation simple and easy to understand. We want to 'just work' for you. We spend a significant amount of our effort on simplifying every step of implementation (this is ongoing and iterative). we've often had complaints from auth0 and cognito users for this. 4. Pricing (compared to Auth0 atleast)
• tarasmatsyk 6y ago
  I really love what you are doing guys. Self-hosted option with SaaS model as an alternative - sweet, perfect pricing balance. I don't know about others but I am really tired of settings up auth over and over again for over 8 years already. Don't give me firebase it sucks so hard I can't even open my eyes when auth needs more control or extension. Im going to give you a shot in my next project
  • rishabhpoddar 6y ago
    Thank you! Really appreciate your kind words :) Have a great day
• madelyn 6y ago
  Hey, this product looks like a pretty decent "stack agnostic" way to handle auth. I've definitely considered using services like Cognito but always returned to "DIY" for the data ownership. A couple questions: 1. How will you keep bigger engineering teams on your platform if access to the data (and therefore migration) is easy? 2. I mainly work with Python. Typically I use Django's user system with my own user model and I copy and paste the client company's "general email template" into the verification / signup / reset emails and I'm done with it. If I need it on multiple services I install a JWT plugin. It takes maybe 10 minutes at the start of a project, and the developer experience is similar from what I have heard in Rails with Devise. Does this service have anything to offer to these "mature" stacks, or are you generally targeting newer ecosystems like Node / "frontend first" projects? Also, your landing page looks great!! :)
  • advaitruia 6y ago
    Thank you! 1. Developers should not be forced to stay with us because they cant leave. The mindset is that the customer is always first and if they find a better solution than our job is to be better than that alternative (not prevent them from going). 2. SuperTokens works primarily with NodeJS at the moment, but we planning on supporting more frameworks like Django. We offer session management (i.e. securely handling of tokens) for the more "mature" stacks since that was what we originally started off with. Once we have traction for one language, we will expand into other ones that users are requesting
• mooreds 6y ago
  Interesting. From reading the website briefly and the announcement above, this seems like a "super library". If there's an auth spectrum, from: roll your own -> use a language specific library -> use a full featured solution like Auth0, Firebase or FusionAuth it seems like SuperTokens is in between the library and the full featured solution. I guess I'd ask, if I don't want a full featured solution (the use case you've identified), why wouldn't I use a language specific library (devise for rails, passport for js, etc). Or is the value that you're providing a modular integration so I don't have to integrate authentication + authorization + user management + API auth myself? Anyways, congrats on launching. We need more auth solutions and I'm glad to see an interesting approach in the open source world. The other major contender, KeyCloak, is, I've heard, a bear to run and extend. Full disclosure, I'm an employee of FusionAuth.
  • rishabhpoddar 6y ago
    Thanks for the comment and disclosure :) We do intend to be a full featured solution. Though, since we are relatively new, we only provide email and password. That being said, our approach is modular in nature so that users get only what they want.
    • mooreds 6y ago
      So if you are aiming to be full featured, the modularity plus open source is your differentiator? What are you going to do if AWS/GCP/Azure decides to offer a managed services version of your software? (I know, I know, that'd be a a great problem to have.)
      • AsyncAwait 6y ago
        AWS etc. already offer these services so the risk is low. I dislike the recent trend of companies changing licenses from a formerly FLOSS solution to "source available". It prevents little in practice and makes it so that your original differentiator i.e. open source is no longer true.
        • 6y ago
• sidhuko 6y ago
  > We think that Auth0, Firebase etc are great services but auth is complex. Yep that tends to happen when you are supporting SSO and certifications like OpenID Connect. Using one SSO portal to handle mobile, spa, web apps and code auth with evolving techniques like PCRE. That's probably why some customisations are not available too because it breaks the standard. You will just end up with the same models once you've implemented all the same features. Okta, Auth0 and others are all really similar because of the standards behind them not because they thrive to be complex.
  • advaitruia 6y ago
    Agreed that the standards make things complex. However, some of them, like OpenID connect are not required for several apps that want just simple email password login (an example). This is where our idea of modules (or recipes) come from. If you choose a module which has nothing to do with OpenID connection (or similar spec), then you do not have to deal with it's complexity. So essentially the way we hope to solve this problem is through our modular architecture. You can start off simple and then just keep adding the modules you need instead of it all rolled into one implementation
• matt_s 6y ago
  I had to scroll thru the website, find docs then click thru to the quick start to discover that this is nodejs. Put the tech used on the front page. You may want to hold back the "Stripe for Auth" tagline until you have more languages implemented. Also you aren't competing with things like Auth0 because if an organization has money for Auth0 why would they roll their own? You are competing with all the different open source framework implementations for Auth.
  • deleted 6y ago
    [deleted]
  • advaitruia 6y ago
    We have a line under the first login GIF that says "Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon". Apologies if this was not evident enough. Will factor this feedback into our UI design process. Certainly, we arent there yet but Stripe for Auth is where we want to be. Based on our experience, we actually do compete with all the proprietary services as well and not just the open source frameworks. When someone (who "has money") is looking for an auth solution, they dont look at which solution is paid. They look at which solution is best for them and that can be either open source, freemium, paid - whatever.
• silasdavis 6y ago
  Ory (https://www.ory.sh https://www.ory.sh) seems to have similar aims, could you contrast? Did you consider their existing code? If you are so inclined also interested in any comparison with https://keratin.tech/ https://keratin.tech/ and https://www.keycloak.org https://www.keycloak.org
• stevemadere 6y ago
  I am psyched about the prospects. Cannot wait to be a beta user.
  • advaitruia 6y ago
    We're so glad to hear! Are you currently working on a project that requires auth? We'd love to have you on :)
• markandrewj 6y ago
  Could you provide some details on where you are storing the tokens on the client side to persist the session? The best practice currently seems to be storing the tokens in http only cookies. I built something not long ago like this for myself. I haven't made it publicly available though.
  • advaitruia 6y ago
    We use httponly cookies too. Yes, we wrote a blog post on cookies vs localstorage too - that you can read here: https://supertokens.io/blog/cookies-vs-localstorage-for-sessions-everything-you-need-to-know https://supertokens.io/blog/cookies-vs-localstorage-for-sess...
• ForHackernews 6y ago
  How does this compare to Keycloak? https://www.keycloak.org/ https://www.keycloak.org/
  • advaitruia 6y ago
    Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak: In general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one (but this is not true for everyone). 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 less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak). Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product. We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm. If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
• pbronez 6y ago
  I really appreciate that you offer your SaaS version for free up to 5K monthly active users! That's high enough that I can actually use this for a side project... $30/mo for the next 5k seems fine. I also appreciate that it's active users.
  • advaitruia 6y ago
    Thats great to hear. We'd love to help you get started with your side project. Feel free to ping us on Discord or on my email ID advait at supertokens [dot] io for any help you need!
  • arcturus17 6y ago
    For comparison, Auth0 also charges for active users, but 10k MAUs would put you at $228. I know some established companies and well-funded startups can pay that without batting an eye, but it seems non-viable for a lot of projects.
• owlbynight 6y ago
  It's like you're speaking directly to me. The only thing I ever use Firebase for is auth and it's cumbersome and annoying. I'm excited to try this. Thank you for having a sensible free tier. I'm a devops/support engineer and I build out small tools all of the time for our teams and I use Firebase for auth as an end-around our IT admin to avoid having to request oauth2 apps via Google every time I need to make something, since all of our people share the same e-mail domain. That's what I'd be looking to do with your product. I've got a project in mind to give it a shot.
  • rishabhpoddar 6y ago
    Thanks for the encouragement :) We will be happy to help when you get started.
• mbullington 6y ago
  SuperTokens looks really cool and I'm glad it's open source, however, I think the big "blue ocean" here for self-hosted auth systems vs. AWS Cognito and Auth0 are security compliance. Many large orgs with data requirements need things like ISO 27001, FedRAMP, etc. If you build with a product like SuperTokens and then need to meet these requirements later in your development lifecycle, you'll have to: a. switch to Cognito/Auth0 for ISO, and for FedRAMP you can only use Cognito. b. modify SuperTokens by learning NIST requirements (costs engineer time, developers might not know Java) c. you can make your own, but that defeats the purpose for these systems (costs more time than b) I feel an "Enterprise" (paid) option by SuperTokens where security compliance is handled, with still the option for self-hosting, would be a massive win.
  • advaitruia 6y ago
    Thats incredibly insightful because that is exactly our plan :) We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail
    • fakedang 6y ago
      > We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail. Just curious about this model, but if you keep only the essential features on the developer plan (good for startups but not much above that), while the enterprise plan requires more complicated features and SDKs that you may not be able to provide just yet because it would be expensive at this stage, wouldn't it be a catch-22 situation of sorts?
      • advaitruia 6y ago
        Sorry, I am not sure I completely understand. When you say that we may not be able to provide because it would be expensive - do you mean it would be expensive for us to build or for startups to buy? What exactly would the catch 22 situation be?
• desireco42 6y ago
  This is really cool. Thanks for making it. Thinking on how I would use it, I appreciate free tier, but I think once things get more involved, I might actually do self hosting, which leaves you without income. I would see about that, otherwise it is cool. If you can't make money, then just when we start using it, you might decide this is not worth pursuing and it wouldn't be good for everyone. Wish you the best.
  • advaitruia 6y ago
    Thank you for the encouragement, we appreciate it! We are happy with developers and early stage startups using SuperTokens for free. Our plan is to monetize feature that are required by enterprises. We have a philosophy section in the pricing page that explains this is more details
• rossmohax 6y ago
  Does anyone knows anything which even remotely comes close to AWS IAM for service to service authn/authz?
• ignoramous 6y ago
  I hear you. The need for something simple is real. I don't have a complex SSO/Auth need, and so, something as simple as single-factor FIDO based passwordless login (such as sawo [0] / portier [1]) or hands-off user management (like userbase [2] / human-id [3]) cuts it for me. That said, the only question I have is the GitHub page says SuperTokens is "open core" > SuperTokens is an open core alternative to proprietary login providers like Auth0 or AWS Cognito. We are different because we offer: > - Open source:... ...So, which parts of supertokens is open core vs open source (supertokens-core, I can see, is vanilla Apache v2 without any strings attached like the horrible Commons Clause)? [0] https://sawolabs.com/ https://sawolabs.com/ [1] https://portier.github.io/ https://portier.github.io/ [2] https://userbase.com/ https://userbase.com/ [3] https://human-id.org/ https://human-id.org/
  • advaitruia 6y ago
    Everything we have today is open source. However, in the future, we plan to monetize features that would be required by enterprises. At that point, we'd be an open core company where a large part of the software would be open source but a few features would be proprietary.
• lmeyerov 6y ago
  Getting Django would be amazing, speaking as a user for whom Keycloak was interesting except not trusting IBM/RedHat as safe & responsible stewards. And we're exactly in that market of 'we want the OSS + on-prem friendly variant for our on-prem users, but a managed service provider for our managed tier.' Auth0 and friends show how big this market is, and the general push to SaaS-only by them and their competitors has been a non-starter. Smart! Unfortunately the focus on nodejs / non-django backends means we won't be evaluating for now -- despite being actively looking at this space. But if you or others become active here, am interested. See replicated.com -- implementing API tokens, RBAC, etc. is necessary for teams like ours yet largely generic, so a good OSS-native partner to pick up where frameworks like Django fall down would be awesome. Good luck!
  • advaitruia 6y ago
    We plan on adding Django support asap. If you could share your email ID or drop me an email at advait at supertokens.io - I will update you as soon as we have the Django SDK ready
• tziki 6y ago
  Out of interest, what's your plan for making a living with an open source product?
  • advaitruia 6y ago
    We will monetize features that are required by large enterprises. Features needed by developers / startups will largely be free. We have a pricing philosophy section on our pricing page that goes into more details about this :)
• mfbx9da4 6y ago
  My specific need is passwordless login (via email currently) to issue private keys for multi device end to end encryption. If you can do that, I'm in!
  • advaitruia 6y ago
    We had actually implemented email passwordless for our own website earlier. We havent launched it yet but are hoping to do so. i'd love to update you when we launch it. Please share your email ID or drop me an email at advait at supertokens.io and I'd be happy to let you know when we have it.
    • mfbx9da4 6y ago
      but with multi device E2E key pairs? That for me is the real challenge.
• timwis 6y ago
  Can you confirm that you don’t recommend storing session tokens in localStorage / anything accessible by client-side JS? (It’s a commonly recommended bad practice these days)
  • advaitruia 6y ago
    Yes, we do not recommend storing tokens in localstorage. This is also recommended by other security bodies such as OWASP and NIST. We've written a blog post on this topic as well, that you can read here: https://supertokens.io/blog/cookies-vs-localstorage-for-sessions-everything-you-need-to-know https://supertokens.io/blog/cookies-vs-localstorage-for-sess...
    • timwis 6y ago
      Great! Pleased to see this :)
• PaulHoule 6y ago
  I wrote this in 2002 in PHP and the world didn't care, it thought PHP nuke was the thing. I got two good jobs out of it so it was good.
• pupdogg 6y ago
  Well, here's the initial commit of RESTful Authentication library from 2006: https://github.com/technoweenie/restful-authentication/commit/2366199ce5bb056565611dcfbe25f6a78930493e https://github.com/technoweenie/restful-authentication/commi.... FYI, still using in production like a charm!
• lwb 6y ago
  Wow, that pricing is awesome. Once you have email verification, social login, and a C# SDK, I will switch away from Auth0 in a heartbeat. This being open source is a HUGE draw. It means I don't have to trust you as much, because the code is out in the open for security researchers to poke at. Do you have a bug bounty program? I assume this works via an API as well, not just web based sessions? My use case is an online multiplayer game written in Unity.
  • advaitruia 6y ago
    Email verification and social login is what we are currently working on. But C# isnt a common request at the moment. We'll definitely try to get to it asap. If you are interested, you could contribute the C# SDK together with us. We do not currently have a bug bounty program. You can use functions exposed via our SDK to verify & refresh a session yourself in your APIs - if that is what you were asking? Apologies if I misunderstood.
    • lwb 6y ago
      That answers it, thanks!
    • keithnz 6y ago
      I'd be +1 on C#, and +1 for SqlServer
  • NicoJuicy 6y ago
    Any reason why you didn't use identityserver to host it yourselve?
  • cksquare 6y ago
    You can have all of the things you're looking for with IdentityServer4. No need to wait!
• pedalpete 6y ago
  As somebody who has never liked implementing login, and I've had some friends who have tried similar start-ups to yours in the past. Who are your customers that are not using one of the cloud providers and want to use an open-source 3rd party? With all my stuff on AWS or Firebase/GCloud, it somewhat just makes sense to use their authentication. Are there cloud competitors you can partner with? I do disagree with the idea that Firebase or Cognito auth are complex. If you're able to build the rest of the cloud service, you're able to build on that.
• abhishektwr 6y ago
  Congratulations on launch and good luck in a very crowded market. We are building something similar with focus on SaaS companies (https://axioms.io/ https://axioms.io/). I really like your multi-tenancy approach - interesting take could be very useful for B2B SaaS companies. We achieve similar outcome using organizations.
  • advaitruia 6y ago
    Thank you! Best of luck :)
• bg0 6y ago
  This speaks to me. I will patiently wait for SSO capability. With that being said, if anyone has built scalable SSO flows specifically Azure AD, and want to help us implement it - please get in touch.
  • advaitruia 6y ago
    Thank you! We appreciate it and hope to make that wait as short as possible
  • abhishektwr 6y ago
    I will be happy to speak. My team specialise in identity and SSO implementations. In fact we also have our own identity product Axioms (https://axioms.io/ https://axioms.io/).
  • ycmimi 6y ago
    We can help. Check it out here. https://datawiza.com https://datawiza.com. Also we are a Microsoft partner.
• headmelted 6y ago
  “We couldn’t afford to pay It took too long to understand the documentation of alternate service providers” These don’t seem like good reasons and would be enough to make me not want to use this until it already has a lot more real-world usage from others first.
  • advaitruia 6y ago
    Thank you for your candid feedback. Those reasons were also echoed in our user research as we were dedicating ourselves to the project. Could you please share why you think those arent good enough reasons? Ofcourse, social proof is important regardless. SuperTokens is being used in the real world, in production. Would you like to see more people using it or some recognizable entreprise brand names?
    • headmelted 6y ago
      It's not the technique that makes me wary - it's that the way it reads is that you've built this because you found the documentation for existing solutions to be too complex which is a massive red flag with regards to anything security related. Essentially it sounds like "doing security is hard so we did something simpler and ignored the complicated parts we couldn't understand". As you've explained it above that's clearly not what you meant at all so maybe edit the website to call out a bit more clearly what your reasons are for building this and what other people's complaints are about existing systems? (Maybe in one of those side-by-side feature matrices showing the benefits of your implementation?) Will definitely check this out when I have some time though!
    • advaitruia 6y ago
      Actually we offer the most secure way of managing session tokens. We were the first provider to implement token theft detection using rotating refresh tokens (and most still dont). Auth0 even uses one of our libraries for solving for edge cases. I dont think that good security = complex documentation. Its about the way you abstract away the complexity. Will factor your feedback when we design the website and think about communication. Please do let me know when you've had a chance to check it out. Would be happy to hear your feedback
• jasonhansel 6y ago
  I really wish there was a sane, simple common standard that all of these identity providers could implement. OAuth is (IMHO) far too complex. Anyone know of any other proposals?
• movedx 6y ago
  For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email address in the database. This has never happened. EDIT: "fault" => "problem"
  • eloff 6y ago
    I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.
    • pwdisswordfish4 6y ago
      > We changed how our sessions work to get around it In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with. The only real quibble here might be that duplicate requests cost you unnecessary transit.
      • eloff 6y ago
        Duplicate POST requests are a violation of the HTTP standard because they are not assumed to be idempotent. I hope you're just misunderstanding the problem.
• cdnsteve 6y ago
  From an SDK approach you might want to start with a generic language library/sdk rather than a specific framework. In Python for example, I see a Flask implementation (cool) but wishing there was one for Django. You will get more miles out of a generic SDK per language, than can be used within framework specific implementations longer term. Less to support and less overhead to test.
• rmason 6y ago
  Please consider adding support for Vue & Nuxt ASAP. Thanks.
• Osiris 6y ago
  I looked around on the site and couldn't find any explanation about how it works, a diagram of the auth flow, or even a gif showing how the flow works.
  • rishabhpoddar 6y ago
    One important point is that we do not follow the OAuth 2.0 protocol since for simple email password login without SSO, we do not need to provide OAuth. So the login part, is a simple API call with the email / password. On success, a session is created, and the flow for that is provided here (in a diagram): https://supertokens.io/docs/emailpassword/common-customizations/sessions/about#overview-of-session-flow https://supertokens.io/docs/emailpassword/common-customizati...
• ycmimi 6y ago
  Guys, why bother integrating different SDKs for different languages and for different IdPs. We provide an App Access Proxy which decouples authZ and authN from your apps and APIs. We integrate Auth0, Okta, Azure AD for you and you just need to put our lightweight container proxy in front of your apps. If you don't have too many apps, it's free for use! Checkout more details here. https://datawiza.com https://datawiza.com
• gfxgirl 6y ago
  Is this similar? https://github.com/Bearer/Pizzly https://github.com/Bearer/Pizzly
• teabee89 6y ago
  Anybody using https://magic.link/ https://magic.link/ ?
• jftuga 6y ago
  How would this work for Windows and MacOS desktop applications?
• solatic 6y ago
  SSO support is a hard requirement, so it's a pass from me. SSO is not an "enterprise" feature. It's a feature demanded by enterprises we sell to. It's also good security practice internally.
• ashwinv11 6y ago
  Hey 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!
  • advaitruia 6y ago
    Thank you Ashwin! Yes, that is the plan. WOuld love to hear your experiences using Cognito!
• ashas451 6y ago
  How would you compare this with something like openam or spring security?
• logicuce 6y ago
  Great 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 company, we let go of that plan. All the best to you and your team!
  • advaitruia 6y ago
    Thats awesome! Thank you
• anonymoushn 6y ago
  I guess not, since it's for nodejs only. I would use it if it had a frontend component and instructions for implementing the backend component.
  • advaitruia 6y ago
    We do have a frontend component as well as instructions for implementing the backend. Currently we support login for nodejs and session management is supported for several frameworks. We will be adding login support in the near future
    • anonymoushn 6y ago
      It looks like step 1 of integrating supertokens is writing a driver, and if I would like to do this the docs invite me to chat about it on Discord.
• kanakiyajay 6y ago
  Supertokens seem great for any startup and many use cases. But a critical part for many enterprise organisations is compliance and strong security. Does it ensure compliance around GDPR, HIPAA, PCI-DIS etc?
• WatchDog 6y ago
  Simple, JWT, pick one. Really don't understand the obsession with JWT, especially if you don't need SSO. Only real advantage of JWT, vs the tried and true random session_id+database approach, is that you don't need the DB. What useful web application needs auth, and doesn't already have a DB?
  • rishabhpoddar 6y ago
    This is a debatable topic. We wrote a blog post about this as well: https://supertokens.io/blog/are-you-using-jwts-for-user-sessions-in-the-correct-way https://supertokens.io/blog/are-you-using-jwts-for-user-sess...
    • WatchDog 6y ago
      The benchmark in that article comparing JWT to opaque session id's doesn't mention what database setup is used or what JWT signing scheme is used. Presumably it's just using a HMAC, I think if it used RSA or an asymmetric signing scheme, the performance would look much different.
      • rishabhpoddar 6y ago
        Yes. It was using HMAC. But I would still assume that RSA would be much faster than a db lookup (in a distributed system)?
        • deleted 6y ago
          [deleted]
        • WatchDog 6y ago
          Perhaps, at least on the JDK[0] RSA can take a few ms, probably a fair bit faster with a native implementation though. [0] https://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml https://www.javamex.com/tutorials/cryptography/rsa_key_lengt...
  • jillesvangurp 6y ago
• deleted 6y ago
  [deleted]
• honestduane 6y ago
  Honestly, Auth0 is cancer for startups and artificially increases the cost of every user. I Really hate Auth0; you should, too.
  • deleted 6y ago
    [deleted]
  • DangitBobby 6y ago
    The pricing model is completely unreasonable. I'll never use or recommend it to anyone.
• DreamFlasher 6y ago
  This is amazing! Wish you a lot of success. Will there be a way to submit feature requests, upvoting and you working on the most requested? Would be great if you would add user management, including profile photos and custom fields in the future. And SMS login.
  • advaitruia 6y ago
    Thank you! We do keep track of all feedback and requests on a private Github repo and use that to prioritize. However, I agree - maybe we can have a public page where users can submit and vote for their preferences. We're excited about user management too! We already have custom fields that you can add to the SuperTokens sign up / sign in form. We'll add passwordless soon after social login / email verification
• mattatkeyboard 6y ago
  Not the same thing, as I'm only ever being the Auth client, but I use the approach I documented at https://github.com/forbesmyester/esqlate/issues/5#issuecomment-575873844 https://github.com/forbesmyester/esqlate/issues/5#issuecomme... . The nice thing about this is that everything behind the NGINX load balancer you don't have to worry about the users being authenticated and / or not. If you need roles / permissions / metadata you can roll that into your one piece of software which handles the client side auth. For something small scale, it's perfectly viable to run it all in a `docker-compose`... For something bigger, I've been hosting it on K8s.
• ecmascript 6y ago
  This looks very cool and I could use it but I would be more happy for an EU version of this where I can simply pay you for hosting it for me, at least until I know my app or project is successful. I think there is a room for a Plausible version of auth. I think it's good that you offer to self-host it but honestly that is a bit of work as well. I use a js-only backend so installing Java as a dependency maybe isn't the biggst deal but it's still something I will have to consider. Even if it's more work to configure and setup an auth myself I will know the intimate details of how it works and don't have to spend time learning another tool in another language. Both takes time and since I've implemented auth several times already it isn't that big of a deal for me.
  • advaitruia 6y ago
    You wouldnt need to install your own JDK. We package it all nicely in a docker container so you do not have to worry about it. This makes running SuperTokens just like running any other http microservice. But yes, your point is valid. If you'd like to be able to know the intimate details and make modifications (that we dont offer), then this would hold true. But all in all, the reasons we picked java were: Java has a very mature ecosystem. This implies that third party libraries have been battled tested. It's strong type system ensures fewer bugs and easier maintainability. This is especially important when many people are expected to work on the same project (for open source).
    • ecmascript 6y ago
      Well, I don't really use docker for my own stuff so installing it to simply use a third party application seems harder than simply installing the software required. I am not questioning your choice of language. It's all fine and dandy I am just questioning myself and if I have enough willpower to actually host it myself. :)
• animesh 6y ago
  I would love to try it. Do you have a plan for a .NET Core SDK?
• brokenwren 6y ago
  It'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 connect with you all as well. Steer clear of Auth0, OneLogin and the others. They don't play fair and I'm positive you'll be receiving your first cease and desist letters in the coming weeks. We have stacks of them and their claims are always total BS. But you don't want to go to battle with a company that has $300M in the bank. Congrats on the launch!
  • sebmellen 6y ago
    You've done great stuff with FusionAuth! I ended up using ORY [0] at my startup as we had slightly different auth needs, but FusionAuth was a top contender. It's strange to me that Auth0 has so much market dominance. Are they a case of VCs subsidizing a subpar product, combined with aggressive (and bordering on false) marketing, or do they really have some unique product? Their pricing seems ridiculous to me; I can't imagine someone doing an analysis between Auth0 and alternatives, and choosing Auth0. But seeing Atlassian switch to them made me think I may be missing something... It would be interesting to hear your analysis of why Auth0 is so prevalent! [0]: https://www.ory.sh/ https://www.ory.sh/
  • krzys 6y ago
    Woah, it sounds really shady... Could you share what those claims were about?
• mderazon 6y ago
  I don't get the Stripe comparison here. Otherwise, looks great.
• Ziggy_Zaggy 6y ago
  Thanks for doing this. I've been waiting for this type of solution for a long time. Let's see how well it works!
  • advaitruia 6y ago
    Thank you! Let me if you need any help setting up SuperTokens
• nudpiedo 6y ago
  Is it there any support for a premade UI like firebase does? that's a great time saver for prototypes
  • advaitruia 6y ago
    Yes, SuperTokens comes with pre made UI. You can choose from one of the three themes we have available and can easily customize the colours / CSS for either of those themes. We also make it possible to easily add your own theme if you like. The docs are here: https://supertokens.io/docs/emailpassword/common-customizations/styling/changing-colours https://supertokens.io/docs/emailpassword/common-customizati...
  • deleted 6y ago
    [deleted]
• resthedev 6y ago
  This is awesome! And it couldn't have come at a better time. I've been working on my own startup product and shopping around authentication platforms. Auth0 looks great but it's just damn expensive when you start getting more users. Appreciate this!