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

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.

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.

Thanks for letting us know about the broken link :)

The reason it says Partial is cause we don't have 2FA with TOPT at the moment. This feature, along with FIDO / webAuthN are in our dev pipeline.

> If I was self-hosting the open source version at auth.mydomain.com would I be able to export the data, load it into your cloud offering and point the domain to your service for a hiccup free transition for site users? What about the reverse?

Yes you can - both ways.

Thanks!

There are other differences too:

- Our architecture is different: We provide a frontend SDK with react components that are embedded in your own website - giving you more control and a better dev experience. The frontend doesn't talk to SuperTokens directly, but instead proxies requests via your backend API layer (using our backend SDK). This makes it much easier for you to customise the backend auth logic (you can reuse your API code and also are not forced to use Java), and also enables us to handle your app's session management out of the box.

- For use cases that don't need OAuth (for example if you have a single website), we don't require you to use the protocol. This makes it simpler to setup auth, especially for people not familiar with OAuth and its various flows already.

- There are other feature differences - some features that we have that they don't and vice versa. But this is just a function of time investment on either side.

Another big factor is the availability of hiring talent. But I guess this already comes under the popularity point.

For example, if you require email / password auth without SSO, then we do not use open ID connect or any of the oauth flows - because those are not needed in a simple setup.

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

This is a debatable topic. We wrote a blog post about this as well: https://supertokens.io/blog/are-you-using-jwts-for-user-sess...

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.

Yes. It was using HMAC. But I would still assume that RSA would be much faster than a db lookup (in a distributed system)?

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