We started SuperTokens 1.5 years ago when we were building a consumer app and wanted our users to be logged in for a long time in a secure way. When it came to managing user sessions, there was a lot of ambiguity. We read many forums (Reddit, Stackoverflow) and blogs, and found that developers were arguing about best practices, such as using local storage vs cookies, implementing JWTs, etc. We had to do a lot of the first principles thinking ourselves to understand the tradeoffs. Around the same time, Facebook, Docker, Gitlab, Youtube, Uber were in the news for session vulnerabilities.

Stealing a user’s session allows you to access their account as if you had their username and password. Hence being able to mitigate against this is important. We’ve audited companies and found large session vulnerabilities that they were not aware of. For a YC company, we were able to pull information on users that we shouldn’t have had access to.

Through our research, we built something internally and decided to write a blog post [1] explaining how our system works. While SuperTokens is not currently open source, you can see the original codebase on Github [2].

Building a good solution for sessions requires a lot of specialised knowledge and time that could otherwise be spent on building your core business logic. Detecting session theft reliably is difficult. There are multiple race conditions, edge cases and network issues that need to be thought about. In fact, one of our libraries that solves a difficult race condition has 100K downloads / week and is even used by Auth0 [3]

SuperToken mitigates against all session attacks (XSS, CSRF, etc) by implementing best practices. For a full list of types of attacks with real life examples please see [4]. However, it is not possible to mitigate against all attacks (for eg: social engineering) and hence, SuperTokens is also able to detect session theft. We use rotating refresh tokens as per the official OAuth specifications in RFC 6819 [5]. Auth0 has also started offering this, but due to their setup, they cannot use httpOnly cookies to store these tokens and this goes against popular compliance recommendations.

Besides security, SuperTokens also offers improved API performance and developer convenience. For clustered and distributed environments, session verification for each API takes < 1 millisecond. You can get a user’s ID and access role without any database lookup. SuperTokens can be implemented in 15 minutes, provides a simple API and has clear documentation. We abstract away complexities of token management by providing frontend and backend SDKs.

In the coming months we plan to offer Access Control, Internal Auth between services and for internal tools (i.e. recent Twitter hack was through unauthorized access to an internal tool), and more! We're still experimenting with pricing, so you won't find this on our website, but we'd love to hear your thoughts about it.

Thank you for reading! We’d love to hear what this community specifically has to say and if you have any experience dealing with this. We’d appreciate any feedback!

----------

Footnotes:

[1] - Blog post: https://medium.com/hackernoon/all-you-need-to-know-about-use...

[2] - Github: https://github.com/supertokens/supertokens-core

[3] - Library used by Auth0: https://www.npmjs.com/package/browser-tabs-lock

[4] - List of attacks: https://supertokens.io/pdf/attackshomepagev1

[5] - OAuth RFC 6819: https://tools.ietf.org/html/rfc6819#section-5.2.2.3