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

[advaitruia]

We (my cofounder and I) have built several startups previously and spent an unnecessary amount of effort on auth. This led us to build an open source alternative to Auth0 and AWS Cognito, that’s called SuperTokens. We’ve spoken to 100s of developers and startups to understand the pain points with current services and we hope you find this useful!

Why did we build this? To be able to control our user data and have it stored in our own database. Have certain customisations that other identity providers do not offer We couldn’t afford to pay It took too long to understand the documentation of alternate service providers

How are we any easier? We think that Auth0, Firebase etc are great services but auth is complex. There are many different use cases for different types of apps. Since services have to cater to each of these, they tend to become complex in their implementation (due to no fault of their own).

SuperTokens takes a modular approach - making it possible to pick only the features you need for your use case. This means you 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.

We are still early in the journey and working hard on building more functionality.

Please see our website: https://supertokens.io/ Our GitHub: https://github.com/supertokens/supertokens-core

Do let us know what you think - specifically whether you would consider SuperTokens for your app. Why or why not? What can we change or offer?

PS: We did a "Launch HN" post earlier when our product was only for securely managing session tokens (https://news.ycombinator.com/item?id=24306572). We realized we need to build more of the auth stack (signup / signin, social login etc) and hence we're excited to announce that we've built basic login functionality.

[movedx]

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"

[OJFord]

FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option).

And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect.

It's especially annoying when setting up a new device - oh right yes, obviously I need to set up my email app before this one...

And what if I don't have or want or can't currently for whatever reason receive email on that device? Now I'm trying to get it there by some other means, only to find it times out in the process.

(This is all happened to me, and enough that I'm ranting about it...)

[pchm]

Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic.

But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth.

Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal.

Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.

[gfxgirl]

I know I'm the exception but as a privacy oriented user I hate this. There are services that try to track me across the net when I'm logged in so I never log into them except in a private window. This works great when my browser has the name/password saved because I go to the site and its one click to login. It sucks though when it's email login. I now have to click "login", wait 10 second to 3 minutes for the email to arrive. Copy the link from the email to the private window. It basically means I avoid using that site most of the time. (Medium)

[eloff]

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.

[sebmellen]

There's a great project called Portier [0], which does this quite nicely. I highly recommend it.

It's a successor of sorts to the ill-fated Mozilla Persona project [1].

> Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.

[0]: https://portier.github.io/

[1]: https://en.wikipedia.org/wiki/Mozilla_Persona

[mooreds]

Another bonus with magic links. In my experience people pay waaaay more attention to their email accounts than they do to almost any other authentication system they interact with. So chances are higher that they'll have a secure password, rotate their password, maybe even have MFA. (I said higher, but I didn't say likely ;) .)

Anyway, I think for certain kinds of applications this is a fantastic auth solution.

The only possible downside is that you've introduced a dependency on mail deliverability into a core piece of your application. But email deliverability may be a big enough issue that you want it solved anyway.

[skinnymuch]

I am not too privacy oriented like another post. I just don’t like having to go to my email to log in. It’s a hassle vs my saved password being auto filled or using an Oauth login. But Most other people seem to shrug it off and do it. So seems like it’ll keep becoming more common.

[protoduction]

I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API.

[0]: https://magiclogin.net

[mekster]

This is just being lazy over customer experience.

I don't like having have to click the link, trash the email and close the previous login tab.

> I can use manual processes to verify the person

What does this mean?

[madjam002]

I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login.

I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!

[miguelmota]

Username + password is nice when you have a password manager that auto-inserts the credentials for you into the form. The 1Password extension and browsers with builtin password managers do this. All I have to do is click login and I’m in. The magic link flow is more of an inconvenience in this regard because it involves jumping around apps.

[artificialLimbs]

As an alternative...I wonder if there could be a auth process where the user creates a writeable 'space' for a site/app with a one time key in their password manager, gives the site/app the key, then the site uploads new login credentials directly into the password manager.

[nojs]

This is so annoying as a user! It’s like you’re making me do a password reset every time I want to log in, and I have to sit there and wait until the email arrives.

[conductr]

I don't mind this. 7/10 times I'm doing the password reset thing already when I visit a site I don't use much but know I have an account with, so this just cuts to the chase

I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link

[pelasaco]

> password handling workflows are now the email provider's problem.

if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)

[jamil7]

I did the exact same for a recent project, a small internal tool for geo data collection in cities. It comes with tradeoffs as others have mentioned but it’s pretty great for getting something going quickly with a small number of users. All you need is mailgun or similar key and you’re off.

[cortesoft]

So there is no way to login on any device that isn’t your own?

[nickthemagicman]

This is a really cool idea.

So they basically go to their email and verify and it stores a token in their cookies?

[corytheboyd]

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 :)

[mbullington]

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]

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

[tracker1]

Funny, I actually wrote a relatively simple auth system that does meet NIST guidelines (by default) and some other security requirements. It sends a JWT token for application usage and can register multiple applications for support, not full OAuth etc. The main application it's used with also integrates into other third party apps, so needed a simple means in-app for auth.

I tried to get permission to develop/publish this application as open-source, but was never able to do so. It's now got a few rough edges only because without the public need/perception some bits aren't as well flushed out beyond our internal use/needs and or the needs of our deployed instances. Not to mention a few requirements to satisfy a difficult architect/lead on another team, and they wound up not using the app anyway.

It's not too hard to meet some guidelines... I wound up using a simple KV pattern for data storage so I could target different adapters, add overlays for caching and encryption etc. There's some cool bits and some muddled bits.

[codingdave]

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]

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).

[rubicon33]

Firebase Auth. One and done.

[jlvdh]

I've been using Nhost backend plus in a project and it has email verification for new accounts: https://github.com/nhost/hasura-backend-plus

[silasdavis]

Ory (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/ and https://www.keycloak.org

[brokenwren]

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!

[lwb]

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.

[arcturus17]

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.

[munchbunny]

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?

[ignoramous]

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/

[1] https://portier.github.io/

[2] https://userbase.com/

[3] https://human-id.org/

[sidhuko]

> 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]

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

[pgt]

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

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.

[Scotrix]

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]

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.

[beachy]

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.

[antoineMoPa]

Keycloak feels a bit like a nuclear power plant control panel to me, so I'm happy to see an alternative like this pop up.

[n_kr]

Keycloak is great software, and I am thankful to Redhat for keeping it open source and maintaining it. But I do not believe that a production deployment of keycloak with HA, backups, customization, integrations, upgrades etc. is easy at all. It takes time and planning to get it right. Depending on the constraints, it isn't obvious to me why it would win by default over SaaS alternatives, or simpler on-premises alternatives like OP's.

[lmcnearney]

I would be careful depending on Keycloak given what happened with CentOS recently:

- https://www.gluu.org/blog/keycloak-is-the-next-centos/

[owlbynight]

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]

Thanks for the encouragement :) We will be happy to help when you get started.

[mooreds]

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.

[defnotanai]

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 or https://github.com/keycloak/keycloak?

[OJFord]

Sick of spending your time on auth, you decided to spend all your time on it?

[cleansy]

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.

[romtx]

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.

[kkirsche]

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?