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.