rishabhpoddar

We don't have that unfortunately. However, a quick hack is to upvote an issue related to the feature you like the most, or create an issue in case it does not exist.

But thanks for the idea! It's a great one.. will have a look at it.

Hahahaha. Fair enough. And it get's even worse when talking about sessions and tokens...

Thanks for the heads up!! We will fix this ASAP.

We plan on supporting it, but don't have a definite date for it as of yet.

We have SDKs for other backend frameworks as well (like golang, laravel...). But those only have a session feature, and not login. Hope this provides some clarification.

The SuperTokens microservice is in Java. The backend can be in anything (like nodejs) - for which we have an SDK that developers interact with.

This is a complicated decision to have made and perhaps a blog post is needed for this. But here is an attempt to answer it:

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

I understand your confusion. You are right, we need to improve our explanation.

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.

For now, it's just email, password login, with forgot password flow and secure sessions. Email verification is next followed by social login :)

Thanks for your feedback

Yea! Integrations with OSO makes sense! We do have plans to support language specific client libraries.

1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD.

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.

Thanks for your comment :)

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

Simpler and open source AWS Cognito.

Yea for those that do not trust a third party, we also offer a self hosted version in which all the data is stored in your own db.

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

Yea! Absolutely. Both our solutions follow the same fundamental idea of changing tokens to detect theft. That being said, there are edge cases that need to be considered when detecting token theft such that there are no false positives: https://youtu.be/6Vzit514kZY?t=747.

The video about describes 2 edge cases specific to our flow, but I maybe they also apply to your solution?

Thanks for pointing it out :)

Thanks! As of now, there is only one version - the pro version. We may add an open source version soon. If we do, it will be clearly mentioned on our site along with what the feature differences between the non-pro and pro versions are.

Noted. Thank you for the suggestions. I may reach out to you sometime in the future :)

I wouldn't consider them as "edge cases" per say. It's an end to end session management solution that aims to be secure and covers all needs for simple and complex apps.

Awesome!! Your site looks really clean! Will reach out!

Not all apps will want to have a good level of session security (as of today). But there are enough that do.

We have a self hosted version that uses your own db to store tokens. So you don't need to give us any "user data".

I see. Thanks for the clarification.

So when you are verifying an incoming JWT, don't you need to check what the allowed counter is for that session? If yes, then doesn't that require a database / cache lookup for each verification? And if it does, then how are you able to get super fast session verification?

Actually yes! We are already working on providing session management for FaunaDB users. Using us, you can easily get a FaunaDB token for a user on your backend and frontend. We take care of all the heavy lifting of creating those tokens and making sure they are alive (and of course, providing session management).

We should have something out in a few weeks from now!

We are in the authentication space. Sessions is a way to get into the space.

Thanks for your comment. There are a couple of points for this answer:

-> Short lived sessions:

A lot of the guidelines (OWASP, NIST, industry compliances) recommend having short inactivity timeouts, and "in session", frequent reauths. Those have clear UX problems, but for apps that are OK with those problems, implementing such mechanisms is good enough, security wise! Most existing libraries easily allow you to build inactive timeouts, but building the frequent "in session" reauth, can be tricky: detecting when last auth happened, saving state of an app between reauths & regenerating session tokens after reauth. Due to these issues, sites end up implementing sessions from scratch and mostly always make some mistake. For example, I have seen banks store session tokens in the page HTML as opposed to HttpOnly cookies. One of our aim is to make it very simple to implement all these best practices recommended by OWASP, NIST, and industry compliances.

-> Long lived sessions:

For all other apps that want to keep their users logged in for longer, frameworks only enable the use of one long lived session token (alive for weeks or months). In this case, if that token is compromised, the user's account is compromised for a long time. Theft of token is possible in multiple ways, even if using httpOnly cookies: https://supertokens.io/pdf/attackshomepagev2

For some people, this risk matters. For them, they want to achieve long lived sessions + reduce the risks of theft. For them, using the existing framework solution is not good enough.

-> Functionality:

There are a lot of functionality that can be required on top of sessions:

- Syncing session data across devices

- Getting all active sessions of a user

- Setting different inactivity timeouts based on a user's role

- Revoking access to a specific device

- Logging in as a user (for support team)

Most of these and perhaps more are required for "serious" apps. Most frameworks do not allow to easily implement all of the above. As result, devs implement their own session solution, and make mistakes.

-> Other considerations:

For many devs, JWT is the goto for sessions (free scalability). Since most frameworks do not choose JWTs for sessions (in their inbuilt solution), devs choose to use something else and make mistakes like storing the JWTs in localstorage.

Incorrectly configuring sessions in these frameworks can also cause issues. For example, during development, secure attribute for cookies is usually set to false. Sometimes, devs forget to set them to true for production use. Another example is that during development, your API is on api.example.com, but your site is on localhost. For this to work, you set sameSite to none, and forget to switch it to lax for production. SuperTokens aims to be very opinionated in order to prevent such mistakes (...catching these errors is not yet implemented though, but soon).

-> Conclusion:

Overall, the in built sessions in the frameworks are good for many apps. However, for those "serious" or complex apps, people end up building something custom (and that's a lot of companies ~ 50% of our YC batch built a custom solution or used JWTs despite of inbuilt sessions in their framework). Our solution is for such people.

Yea! That's why we have a frontend SDK that solves for issues like these. Our SDK uses a library called browser-tabs-lock which provides locking across tabs (https://www.npmjs.com/package/browser-tabs-lock). So essentially, whenever a refresh call is made, we synchronise those requests.

This library is written by us to solve for the exact problem you mentioned! It's also being used by Auth0

Thank you :)

We can add that to our roadmap. We are also happy to prioritise depending on your use case and commitment! Do reach out to us via email (team@supertokens.io)

Sounds interesting! I'll have a look at your library. Our solution takes relevant aspects of the OAuth specs. Specifically the idea of using rotating refresh tokens to detect session theft.

That being said, we have not had any formal verification. We plan on doing an outside code review / audit from a reputable 3rd party in the coming weeks.

Two question for you: - In your solution, I assume there is one JWT per logged in user. If I want to revoke one user's session specifically (without affecting other users who have a similar count), how would I do that? - When would I want to revoke all sessions before some count X?

Apologies if I have misunderstood how your lib works.

I understand that this is annoying. The reason we have it that way is cause we are experimenting with pricing on a per user basis - it's like the "contact us" pricing plan for other SaaS products.

Soon, we plan on standardising pricing based on our pricing experiments. Thanks for the feedback!