- π What is SuperTokens?
- ποΈ Architecture
- π₯ SuperTokens vs Others
- π΅ How will we make money?
- β Why Java?
- π οΈ Building from source
- π₯ Community
- π©βπ» Contributing
- π Development history
- π License
If you like our project, please π this repository! For feedback, feel free to join our Discord, or create an issue on this repo
SuperTokens is an open core alternative to proprietary login providers like Auth0 or AWS Cognito. We are different because we offer:
- Open source: SuperTokens can be used for free, forever, with no limits on the number of users.
- An on-premises deployment so that you control 100% of your user data, using your own database.
- An end to end solution with login, sign ups, user and session management, without all the complexities of OAuth protocols.
- Ease of implementation and higher security.
- Extensibility: Anyone can contribute and make SuperTokens better!
Authentication directly affects UX, dev experience and security of any app. We believe that current solutions are unable to optimise for all three "pillars", leading to a large number of applications hand rolling their own auth. This not only leads to security issues, but is also a massive time drain.
We want to change that - we believe the only way is to provide a solution that has the right level of abstraction, gives you maximum control, is secure, and is simple to use - just like if you build it yourself, from scratch (minus the time to learn, build and maintain).
We also believe in the principle of least vendor lockin. Your having full control of your user's data means that you can switch away from SuperTokens without forcing your existing users to logout, reset their passwords or in the worst case, sign up again.
ββββ We want to make features as decoupled as possible. This means, you can use SuperTokens for just login, or just session management, or both. In fact, we also offer session management integrations with other login providers like Auth0.
- Login (coming soon):
- A decoupled login & sign up form as React components - pretty by default, but fully customisable.
- Email & password login with email verification, and forgot password flows
- Extensibility to build other methods of login - for example passwordless login.
- Extensibility to chain various login challenges
- Password management - hashing + salting.
- Social and other types of login
-
Session management
- Create, verify, refresh & revoke sessions.
- Follows all session best practices like using
httpOnlycookies. - Prevents common session vulnerabilities like session fixation, CSRF or brute force attacks.
- Detects session hijacking using rotating refresh tokens.
- Optimal time and space complexity - session verifications < 1 MS
- Automatic JWT signing key rotation, without logging users out
- Ability to get all sessions given a user ID.
- Reading session data on the frontend, securely.
- Manipulation of session and JWT payloads
-
User management (coming soon)
- (Un)banning & deleting users
- Resetting user passwords
- Associating users with roles
- Login identity consolidation (if a user logs in via google and via twitter, with the same email, they are treated as the same user).
As of now, we only offer session management.
The docs can be seen here
A short implementation video
Please find a writeup about this in the wiki section
Please contact us if any of the information listed below is incorrect.
[1]: For enterprise version only
Our philosophy is inspired by Gitlab's buyer-based model and by Enterprise Ready. This means that we intend to monitise on features that are targetted towards users who are not developers, like product managers, customer support teams, designers, admin teams and IT operations.
This implies that most authentication / authorization features will be in the open source version for any scale - an unlimited number of end users, (social) logins, SSO integrations and much more.
Examples of features that will require a subscription:
- Access control features for the dashboard (for managers and execs)
- SSO / LDAP / MFA login to the dashboard
- Roles to restrict access to parts of the dashboard.
- Creation of custom roles for dashboard operations.
- Healthcheck and uptime monitoring (for IT dept.)
- Cluster health stats
- Integration with services like PagerDuty
- Features to make operations easier for customer support agents
- Login as a user
- Manually send login OTPs
- Advanced analytics features (for product management & design teams)
- Sign up form A/B testing
- Advanced security (for compliance and security teams)
- Detailed audit logs of dashboard and end user actions
- Encryption of stored information
Outside of the open core model, we will also charge for:
- Hosting of the SuperTokens service on our cloud.
- Completely managing the SuperTokens service on your cloud.
- A commercial license that dictates:
- Different levels of support
- Liability agreement
- Building custom features
- Backporting updates and security fixes
- Java has a very mature ecosystem. This implies that third party libraries have been battled tested since a very long time. This adds an additional security benefit.
- Java's strong type system ensures fewer bugs and easier maintainability. This is especially important when many people are expected to work on the same project.
- Ability to dynamically load JARs allows us to distribute only the right database plugin, minimising the final Docker image size.
Please see our wiki for instructions.
If you think this is a project you could use in the future, please π this repository!
Rishabh Poddar |
![]() Advait Ruia |
Bhumil Sarvaiya |
![]() Joel Coutinho |
Rakesh UP |
![]() Mufassir Kazi |
Nemi Shah |
Rohit Bhatia |
Madhu Mahadevan |
Please see the CONTRIBUTING.md file for instructions.
Over the last few months, we have built out session management for SuperTokens. During this period, we have made our fair share of mistakes:
-
Our first version was architected such that it tightly coupled the backend and database layer. So we had one
npmlibrary for NodeJS with MySQL, and another one for NodeJS with MongoDB etc. When adding support for a new backend framework, majority of the logic and tests needed to be rewritten. It became clear that we needed to add a service in the middle. We do realise that adding this service means it's harder to get started and that there is an extra point of failure, however from the perspective of supporting each tech stack, this decision makes sense, since the failure problem can be addressed through easy to implement technical means. -
Until August, 2020, our license was not truly open source. This was done as an experiment to get feedback on the importance of software license for the startup community. Since then, it's become very clear that we must use a standard open source license, so we chose Apache 2.0
-
Our community version used to ping our APIs from time to time. This was done for us to understand adoption of our session management solution. However, it quickly became clear that that was a bad move.
-
We used to have a notion of a license key that was required to use the community version. This license key was issued by us, and would never expire. Some parts of the code still refer to that, however, it's only for backwards compatibility. For all intents and purposes, a license key doesn't exist for this version, which means anyone can build from source, and use SuperTokens for free, forever.
Β© 2020 SuperTokens Inc and its contributors. All rights reserved.
Licensed under the Apache 2.0 license.




