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.
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
> 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?
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?
What Aeolun said. Basically if you don't provide those features that enterprise wants from the get-go, and count on the enterprise plan to fund the development of those features, doesn't that land you in a catch 22?
Not that I'm criticizing your model, but I'm just genuinely curious. I would switch to using this in a heartbeat if it doesn't end up too complicated. And lots of thanks to other HNers for downvoting me when I asked an honest question on SaaS pricing.
FusionAuth (the company for which I work) have a similar model with a free (though, in our case, not open source) community edition for developer reach and to lower the barrier to entry.
Then support and enterprise features are paid for by the enterprise. If you can find the right levers, it works.
This has been a common business model. Redhat did it, Hashicorp does it, Rancher I believe as well. The entire SSO Tax group of companies ( https://sso.tax/ ) have variable pricing because companies will pay for features like SSO that devs won't.
I think the jury isn't out on opencore as a business model and auth is certainly the right kind of horizontal platform play. And there's certainly room for all kinds of business models in auth, as it's a gigantic market.
As a (potential) consumer of this type of service I can attest that this is fine with me.
I had a SAAS for a while where <large enterprise customer> insisted on SAML-based authentication for a full roll out. However, they were happy to do a (cheaper) paid trial without it.
A service like SuperTokens works well here because its costs and complexity scale with my requirements. Unlike Congnito it is literally free and completely under my control at the start, but there is a reasonable forward migration path that doesn't involve a complete auth rewrite going forward.
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.
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.