Supertokens: Open-Source Alternative to Auth0 / Firebase Auth / AWS Cognito
github.com212 points by nateb2022 2 years ago
212 points by nateb2022 2 years ago
This is an Open Core product. The open source part of it seems to be quite limited (see https://supertokens.com/pricing) and therefore I have a hard time believing this version can be "an alternative to [...]".
Actually, the main motto of the frontpage is "Open Source User Authentication", which I also think is a bit of a mischaracterization of the software, since key features I'd look for on an authentication software are not open source.
I love that this is a Java-based project and the goals and ideas behind it; but I think the so prominent use of the terms "open source" is misleading and I recommend demoting them or using alternative terms to reflect a more precise reality.
Many of the core features are open source. Eg all the authentication methods - email password, passwordless, social etc are all in the open source product. You can also use the open source components to implement email based or SMS based 2FA.
RBAC, session management and user management dashboard are open source too. Its several years of an engineering team's work that is all open source.
Our philosophy is to keep features that are broadly required by developers and small companies in the open source version. Things that large companies require, will be source available.
We have several enterprises (more than $100M raised or several hundred employees) that are using SuperTokens at the scale of millions of monthly active users - all using the open source product. We think the open source product is a sufficient alternative (for a large enough population).
Are there any other features you feel should be in the open source version? Happy to hear any feedback and improve
(Project creator here)
> Many of the core features are open source.
Out of the 15 features I see in https://supertokens.com/pricing, 7 are only proprietary. That's roughly half of them. Without qualifying the weight of every feature, it numerically raises a significant challenge to your statement.
SAML, OAuth and 2FA strike me as key components for me that are not open source.
---
So I stand by my words. I feel put off by a wording that makes me believe a project is open source, when it is open core. Even if you don't like open core or argue the definition is not clear (which I'd disagree), at least marketing it as open source so prominently is IMO misleading, and puts me off (and apparently I'm not alone here).
It's fair to have a business model on open source (obviously!) and I wish you all the luck. But being honest about your business model choices should be the #1 tenet.
|| Without qualifying the weight of every feature, it numerically raises a significant challenge to your statement.
Well i think that is the only thing that matters.
If I split all auth methods into the 6 different features it really is, then it becomes 13 free features.
The ones listed as not open source is to indicate what we plan to build for our paid offering. If we removed those and 13/13 were open source, would that change your views? If yes, then that qualification is pretty important.
SAML client and OAuth client are both free. You can add auth with any OAuth 2.0 provider to SuperTokens.
Being an OAuth 'provider' (emphasis) is not open source as it is a feature you need for complex use cases.
You can add 2FA with email or SMS in the open source product too (just requires some customizations and overrides)
> Well i think that is the only thing that matters
It's not the only thing that matters. It may matter more, but not all. Yet since I'm not your CPO/CMO I won't get into the effort into analyzing their weights ^_^
> SAML client and OAuth client are both free. You can add auth with any OAuth 2.0 provider to SuperTokens.
I'm not denying what you say, but in your pricing page I read:
* "SAML Auth" --only proprietary version
* "2FA" --only proprietary version
so if they are open source, this feature naming is confusing.
We can go back-and-forth debating the merits of the non-open sourced features. But that doesn't change the gist of my comment: you are advertising something as Open Source, where only a fraction (big or small) is, and I consider this misleading. At least for me. I find it more honest to remove that prominent Open Source calls and instead replace for less prominent comments about part of your software being open source (which is fine and great!). But this is just my 2 cents, take them or leave them ;)
[Edit: formatting]
Agreed on feature naming - will fix!
Also I definitely understand your perspective and it makes sense. SuperTokens still is 100% open source - but you are right, as we evolve into a paid offering, there is scope for improvement
> Being an OAuth 'provider' (emphasis) is not open source
Being an OAuth provider is precisely what everyone expects from a self-described "open source authentication service". If Supertokens does not support that out of the box, it should not really be called an open source authentication service.
I understand you want to capitalize from your work, but I feel this is a gross misrepresentation of a project.
How does this differentiate from other open source identity solutions like KeyCloak or Ory? I wish there was more collaboration in this space, especially singe we’re talking security and these projects need pen testing, bug bounties, and more infrastructure to be considered „production grade“.
There is a comparison chart available: https://supertokens.com/pricing#comparison-chart
Quite a confusing comparison, especially against Keycloak. From what I can tell the open source part doesn't seem to do anything Keycloak doesn't do, but many of Keycloak's features aren't on the list.
The chart also assumes you're using the hosted solution (as 2FA isn't even available on the open source version according to that same page). If that's the case, it should compare against any hosted Keycloak provider, because SLA and management are readily available. I suppose the table could also compare the open source versions, but that wouldn't be very advantage to SuperTokens with major features still marked "coming soon".
I'm not sure why Keycloak wouldn't offer "UI and backend customisability". The theme guide shows quite a lot of customisation (https://www.keycloak.org/docs/latest/server_development/#the...) to the point where you can restructure the HTML itself.
One thing Keycloak lacks is an easy to use API, using complex OpenID/OAuth/etc. APIs and two language specific libraries instead. That seems like a much more sensible option to distinguish between these products. As someone currently using Keycloak (and not experiencing any problems with it after setup) this comparison just isn't very convincing.
If you ignore the subjective lines two and three of the comparison table, keycloak looks objectively better. And it has an Apache 2.0 license for the whole product.
Honestly, thanks for putting keycloak on my radar.
I see the supertokens team in this thread doing nothing to make me think that they intend to stop misleading people.
I'm happy with the way I've got Keycloak set up (especially ability to simply throw Apache's OpenID Connect in front of arbitrary paths) but I do recommend also looking into alternatives. Keycloak is great for enterprise SSO setups where you need to authenticate to ten different services on ten different domains, but there are much simpler options out there if all you need is auth for a single website!
I imagine the biggest reason to go for Supertokens is the first-party SaaS support. If you want to outsource auth (like Auth0/Firebase Auth/etc. do) then I think there's something to be said for this project. The open source-ness doesn't add too much value in that use case, though.
Supertokens also allows you to implement enterprise SSO through their integration to SAML Jackson (by BoxyHQ).
And when you include Keyclokify[1] the UI customisability is a breez. This comparison really isn't giving the full picture and capability of Keycloak.
Right. Makes sense. I think what we had originally intended to communicate is the ease of customisability, in which case, we feel that Keycloak's UI customisation is more difficult to do.
Putting user satisfaction in the chart and not backing it with sources (I know at least a handful of companies who are very satisfied with e.g. KeyCloak) does not instill lots of confidence in the product differentiation. And what does customizability mean? KeyCloak has a rich Plugin system.
Other than that it seems to be quite equal, if you discount the more difficult things in Auth like providing standardized APIs, OAuth2 APIs and SCIM.
Yes, its a very subjective point.
We've mentioned the source (if you hover) and it is based on our internal user research and conversations with users of these products. By no means is it perfect and there are many many satisfied customers of each of the other products.
Your point is taken though and maybe we will edit that point out or try to add further nuance.
I do believe however that broadly speaking, that reviews of keycloak lean towards it being relatively harder to use and maintain than Firebase. Arguably the reviews of Cognito are more mixed than "Low"
It's tricky to make these marketing charts objective. It would be good to have a real comparison somewhere.
To add on to the comment about Keycloak, the comparison to AWS Cognito has a couple issues as well.
- The comparison suggest Cognito is more expensive. Cognito pricing starts at 50,000 MAUs for free. That's 10x the size of the SuperTokens free tier. It then tiers from $0.0055 down to $0.0025. That's 1/3 to almost 1/10 of the SuperTokens hosted open source option. MAUs who use SAML or OIDC are another $0.015. That's still equal to or less than the SuperTokens hosted open source version where SAML isn't even available.
- Multi-tenancy is a complex topic. But a common pattern using Cognito is to create a User Pool per tenant which provides a lot of flexibility depending on the number of tenants you anticipate.
Saying that GDPR is not needed because Keycloak is self-hosted is just outright wrong, which makes me wonder if the creators understands GDPR and how valid their claims to support GDPR is.
I am more interested in Logto than supertokens https://github.com/logto-io/logto
Why?
I work for another auth provider (FusionAuth), so always interested in learning about other solutions.
What's Logto's special sauce? I see it uses the MPL and is a CIAM solution, written in Typescript. What else is unique about it/why should someone pick it over the other options?
Nice product. It's always good to see more choices in the authz space.
I think Ory (Kratos) is a critical omission in the comparissons page, given the Ory suite seems to be one of the top alternatives currently for OSS authz/authn.
Hopefully the omission is fixed soon.
For some people the missing OpenID Connect may be a feature. But it provides some sort of vendor lock-in. A lot of components can easily be attached via OIDC and i would not use an authentication provider/middleware without OIDC support.
Disclosure: I work for FusionAuth, a competitor.
Yes, OIDC is quite important for the central identity hub, especially when you get beyond custom apps. If you are building an app, Supertokens with their SDKs and APIs might be a great choice.
As soon as you start wanting to integrate with other COTS or OSS applications (a forum, help desk software, slack/teams), you'll need OIDC (or perhaps SAML, depending on the age of the software) support.
Fair enough. We are in the process of adding this feature.
That would make integration with Wundergraph possible: https://docs.wundergraph.com/docs/auth/cookie-based-auth/ope...
For those concerned about the license, you can go right ahead and fork the open-source parts and start coordinating the development of any of the non-open parts on your fully open version.
Personally, I appreciate the parts that have been made open and love that they could be the foundation of a fully open solution that is viable for organizations of any size.
There is no offense in doing this, as this company has intentionally selected to license part of their code to facilitate thus type of competition in the software eco-system.
They are betting than no one could sustain an fully open alternative, and therefore their open-core business model is viable. Maybe they are right-- maybe not.
Any solutions for Elixir and Phoenix, we currently have component and live view is leveling up quite nicely to be able to isolate the auth from the DB/App.
This is one example where OIDC support would be great. Elixir has a library with OIDC support: https://hexdocs.pm/openid_connect/readme.html
We don't have SDKs for these yet, but you can always spin up a node process with our node SDK and use that as the auth server for your Elixir app. The node process would create a session and issue JWTs to the frontend which can be sent to the Elixir backend for API auth.
Another open-source IAM solution called Casdoor looks better than supertokens, it's fully open-source https://github.com/casdoor/casdoor
Not fully open source and run by a tiny startup that last raised funding 3 years ago means it's way too risky to use in a real product. Firebase and Cognito have issues, but for something as mission critical to a product as auth and identity knowing the service won't be killed or acquired is too important.
We've raised money every year in the last 3 years. We just dont update crunchbase.
we're being used at scale of millions of monthly active companies by very large companies - which have done deep technical evaluation.
If the company dies or gets acquired (possible with companies of almost all stages), the product is actually open source. You can self host it without any permissions and we provide daily database backups
"open core" != open source.
I've been burned by too many YC startups that go away and leave customers stranded to use one for something as important as auth.
"[...] it is forbidden to copy, merge, publish, distribute, sublicense, and/or sell the Software." [1]
"Open source is source code that is made freely available for possible modification and redistribution." [2]
[1] https://github.com/supertokens/supertokens-core/blob/master/...
That is the license for the contents of the "ee" directory. The top-level LICENSE is Apache 2.0.
I don't know to what extent this code is integrated into the rest, but it's a valid way to develop open-core software.
"The concept of open-core software has proven to be controversial, as many developers do not consider the business model to be true open-source software. Despite this, open-core models are used by many [...] software companies." [1]
[1] https://en.wikipedia.org/wiki/Open-core_model
I rather go with this definition. Opensource != opencore. Despite this, you're right, that is the license for `ee` folder.
IMO it's fair to call it open source if you can reasonably use the open part of it in its own right, if the core stands alone and there's just some closed source plugins or whatever.
Where 'open core' is to be scathingly applied and '!= open source' etc. is, IMO, when you have a system with only some piece open, and other integral pieces not. Like an open backend but closed source clients, keys required so a third-party client wouldn't work anyway, etc.
That is because you are cherry picking the ideas you want from the wiki page. The first line reads:
> The open-core model is a business model for the monetization of commercially produced open-source software.
The open core movement is about finding a way to financially support open source development so people can eat and work on open source. It is quite obvious that the model which makes some of the code open source and some of the code not, is the best model we have right now. Some of the best open source is produced by these for profit companies. What are the alternatives? We'll before this model gained popularity, there was low quality open source or closed source alternatives for many of the projects we enjoy and see competition amongst today. All of this leads to a more vibrant software ecosystem.
Do you support open source in words or money?
I was with you up until that strange closing question.
The biggest complaint from open source maintainera is around freeloaders. People want projects and support for free, from primarily volunteer developers. Many toute the benefits without putting money where their mouth is. The open source community is more actively trying to figure out how we can support the creators, than it ever has been.
The question is about reframing how one thinks about their support of open source. The GP that is arguing that open core does not count as open source seems like the kind of open source user that wants it for free from volunteers without consideration for the effort and compensation that it requires and deserves. Open core is a valid way to build and support open source IMHO.
Could they make it open source by turning it into a library that a separate EE repo with a different licence includes? Would that stop it being open core?
I think it depends on the feature set that is available in the open source project. Often that exists to lure people in, but they quickly find out that the project is too limited or even crippled and they need the EE parts for an actual production-ready solution.
What features of supertokens are not open source and part of that "enterprise" directory?
As of right now, nothing. The only thing that is in there is a license key checker and basic infrastructure for feature flags.
I see a feature flag and a license check class.
https://github.com/supertokens/supertokens-core/tree/master/...
I am always wondering: If I take the ee directory and garble it through a LLMA, is it protected by copyright?
Does GitHub Copilot take the license change into account for the ee directory, or does it take the tag from the main directory?
I mean, if you--as a human--read that code yourself, learned how it worked, and then tried to write something similar later--even in a different programming language!--that is highly likely to be contaminated and considered a derivative work <- this is the reason why clean room design--where you have one team look at the original to write documentation which is then cleared by a lawyer to not contain any expressive intent before being handed to a second disjoint team to implement--is a thing people have to do. That GitHub Copilot is somehow afforded some kind magic assumption that it perfectly removes expressive intent is kind of ridiculous and highly unfortunate.
I find it terrifying that this type of reasoning is actually legitimate law.
Think about all the drive by licensing felonies everyone has comitted by accidentally reading open core code and then, at a later point implementing something vaguely related....
EDIT: Typos & punctuation
IANAL but that's why law has to be interpreted by judges rather than being a book of absolute rules.
Lots of codified laws are bent or modified by prevailing social attitudes, customs or precedent, so you could argue "I looked at it a couple of years ago and then independently decided to implement something similar" is a very different situation to "we read through the code and a week later started on a competitor".
Whether you'd get away with it is another matter, depending upon interpretation and perspective.
The clean room described above is a fairly bullet proof technique, but it's only been employed very few times and is not necessary to create an original work. Nearly every work was produced by people who were exposed to other copyrighted works. Unless something is a straightforward copy, it's a high burden to show that something is effectively a copy or translation. A lot of these kinds of things are untested in court probably because it's so difficult to make an abstract case.
Good question.
Does LLM prompt conversion erase license? Probably no.
Does LLM training erase license? ClosedAI argues yes.
Legislation is missing around it. There are many smooth sliders that blur line between yes/no where on one extreme it’s definite yes and on the other definite no.
Hmm, to be honest, I don't know. But I just found an article from Codeium and they stated some problems with licensing stuff with GitHub Copilot, here: https://codeium.com/blog/copilot-trains-on-gpl-codeium-does-....
Bonus-Question: If I am a malicious actor and just want to argue, obfuscate the fact that I blantly stole the code. Could I just prompt: Refactorate this code? Would somebody notice and could it hold in court?
This would, of course, depend on the code. But you could ask it to rewrite the code in another language, and add it; claiming it was your own work (which it is, just using an AI tool) This again opens up the debate of AI generated vs 'hand written' code...
All the features you see on github / the website is under the apache 2.0 license - truly open source.
The only code in EE so far is the feature flags. We will implement certain "source available" features in the future
Honestly, I'd just make 2 repos if possible. One open source; the other that includes the first one as a library, that has a commercial licence.
Then instead of the "open core" debate (which whenever it can be solved by 2 repos seems specious), you have an open source piece of software and you get points for letting people see your enterprise licenced source code as well.
Open-source founder of another startup/open-source project with an ee piece [1]
Separating the repos is a HUGE hassle which is why you never see it anywhere. Doing it once is a small cost but maintaining is a huge burden on teams that are already too small. In practice it does not change anything so most projects will choose to suffer nit-picks.
Question: Why not call your self an open-core founder? My point is, a license model should not be abused an advertisement term. The definition of open-source is pretty straight forward. Also the term open-core. And i do not agree, that is doesn't change that much. From a marketing standpoint, it really does. As the term "open-core" is so much weaker than "open-source". It is a HUGE hassle so sell this, instead of the other. And is classical wording BS and the wrong label as the open-core is much more precise. At least for me, i would not have clicked on this if labeled open-core. I guess that is why projects don't want to do it. But even worse, and that is why i think it is footgun, after reading the actual license terms, i felt fooled and leaving for ever. And that's sad part of this story.
How do you define open-core ? We and I suppose it's the same for supertokens literally only have features in ee that large enterprise would care about like scaling to hundreds of workers. Would you prefer that we never develop those features ? What difference does it make if we develop those plugins in the main repo versus another one ? Would you prefer that those features to be hidden from sight so you cannot even read the source ?
I might be wrong but open-core is for me products that expose the minimal amount of features as open-source but are only really usable with the proprietary glue. That is not the case for us.
That is not a strict understanding of that term though! That is just an anecdotal opinion. Open-core is where part of the codebase is open, while another part is not. Plain and simple.
And that is not the same as Open Source, which is absolute. The whole reason the term open-core came about was to disambiguate projects that could not claim 100% open code, and make it easier for consumers to pick based on that commitment (or not).
Either you're open source, or you're not. Open-core is not open source. Just be transparent and we're cool.
Not everyone agrees with your particular definitions.
not mine but wikipedia definition. you can fight with the wikipedia guys about yours. good luck with it.
Wikipedia is not an authorative source and the open source foundation is just some people who decided to name their org that.
But there is no contradiction to wikipedia definition. The fact that there are optional non-OSS components doesn't make the whole thing non-OSS.
It's not that different to using linux with non-OSS modules.
I don't think this is a general principle. It just depends on the codebase in question.
There isn't a singular definition of open source that everyone agrees with.
Bullshit. "Open Source" is well established, and has been for just over two decades:
That some people - like yourself - want to muddy the waters is neither here nor there.
No. That's just some people who registered a website and put up their organizations definition. The website milk.com doesn't get to define what the word milk means, either.
To some people Open Source means that the Source is publicly viewable. It doesn't say anything about your rights to use it commercially. This is why people often bring up definitions such as "libre", "free as in beer" or "free as in speech"
Heh, yeah good luck with that.
The real question is why are you trying to muddy the waters of the existing term, rather than inventing your own term and getting people to use that?
Like I already explained to you, not everyone agrees on the definition of open source. You have your definition, the open source foundation has theirs, and other people have their own. It is not a well defined term.
Why are you pretending you get to define the english language for everyone?
[dead]
Stopped reading at "Why Java"
The fact that it's written in java made me lose interest. I just can't afford hiring a jvm specialist to tune jvm deployments
We provide a docker container which manages running the SuperTokens core (the java part) for you. You can easily run several of these behind a load balancer and scale to millions of MAU. We have several users who have done this with no java knowledge whatsoever.
Why would you need to tune the JVM, and why would you need a specialist for that?
Well you really should manage the amount of memory available to Java.. ie the -Xms and -Xmx values at high scale. That generally all that’s needed 95% of the time. Maybe the commenter is not comfortable with this?
It doesn't sound like a specialist task if it happens 95% of the time. The commenter just wanted to bash Java for no reason.