Sick of spending time on Auth, we built an open source 'Stripe for Auth'
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.
347 comments
[ 5.1 ms ] story [ 286 ms ] threadIt 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.
I know "me too" comments might not be the most helpful but... this sounds like the only blocker for me too!
But thanks for the idea! It's a great one.. will have a look at it.
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.
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
[2] https://www.styra.com/
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.
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.
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
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.
Typical multi tenancy implies that the auth experience and data is isolated per tenant. However, often b2b companies simply want to provide an auth experience to their client within a specific subdomain. They do not mind the auth data be stored in the same db tables as other clients. If this is the use case, then we do support it. If you want strict isolation of auth per tenant, then you will have to deploy multiple instances of the SuperTokens core (as of today).
Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?
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.
I confirm that, we had a bunch of problems with upgrades in one product. In long term keycloak introduced more headaches for ops than we devs had implementing integrations with auth0 or okta. That was before KC10.
- https://www.gluu.org/blog/keycloak-is-the-next-centos/
Baseod on the rest of your comment, I think maybe deplorable was not the word you intended to use there?
Still sad that Persona died before it could gain some traction.
(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.
And yes, indeed. We will add the option where our SaaS will also write to your own DB as opposed to ours.
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!
> 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.
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?
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?
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.
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.
I might be off base here, but does anyone really leverage social logins anymore? Seems like it's the worst case scenario for auth in the case that a customer can no longer access the associated social account? Basically in every case you'd have to provide an antiquated flow for them to "re" sign-up with an email. I'm genuinely curious of the value add here, outside of using Sign In With Apple (since it parlays nicely into Apple Pay integrations).
I'm sure there are on tiktok and other popular social apps.
The project really needs a great frontend. Right now it's mostly just a an API with all these features. It's also MIT licensed:
https://github.com/curveball/a12n-server
Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.
Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.
But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.
And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.
Edit: open source part = huge. Great work
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).
Ooof.
> Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon
That's a very very odd combination.
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.
The backend API queries the core for sign in / sign up / sessions etc... This can be in any framework, and we decided to choose NodeJS first. Here, the user does not have to interact with Java at all.. just simply use our NodeJS SDK that internally calls the core's APIs
Thanks for your feedback
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?
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..)
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?
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.