Session security is an important consideration in the design of any system that requires communication between a server and a client. OWASP (Open Web Application Security Project ), the leading authority for security, considers the improper implementation of authorisation and authentication as the second biggest threat to application security. Several notable hacks illustrate this point:
- A software bug made it possible to steal access tokens — affecting 90 million Facebook accounts. Source
- Gitlab had a vulnerability where all its user’s auth tokens were exposed in the URLs, had no expiry time and were susceptible to brute force attacks due to their short length. Source
According to former Box Inc Chief Security Officer, this is the number one spending cost for organisations when it comes to their security budget. Source
There are two aspects to session security - prevention and detection. SuperTokens aims to be the best session management solution to both of these problems.
In the “Session Attacks” section we discuss the different types of attacks that are possible and how SuperTokens mitigates against them. However, tokens are fundamentally susceptible to theft (they are transmitted to the frontend) and hence detection of token theft is an important line of defense. Infact, as we will see later, the official OAuth 2.0 specifications explicitly mention that services should incorporate methods to detect misuse of tokens.
Session attacks (Prevention)
Auth tokens are stored on the frontend, the backend and are frequently sent over the network (depending on the session flow). As such, they are vulnerable to several types of attacks.
SuperTokens implements the best practices to protect against each type of attack - something other libraries may not do. Building a secure session flow would be a time consuming process as one would need to learn about each type of attack and implement security measures accordingly. SuperTokens does this out of the box.
Types of session attacks:
- Social engineering
- Database access
- OAuth token theft
- Man in the Middle (MITM)
- Brute force
- Session fixation
We chose to start with Social engineering as this is an example of an attack that is impossible to prevent. An attacker with physical access to a victim’s device can steal auth tokens in multiple ways.
- An attacker could simply read the cookies (even if they are secure or HttpOnly) by inspecting the application page if the service is accessible via a browser. On a mobile app, this is harder but still possible.
- Depending on how an app’s session flows are implemented, an attacker could steal a user’s auth tokens even after the victim has logged out of the app. This video from 2013 shows how Twitter did not invalidate the session cookie even after the user logged out. As a commenter points out, this was still occurring even in 2016!
Both of the above issues are even more probable if an app is being used on a public computer.
Consequence: Individual user’s account compromised
Mitigation: There is no way to prevent physical access to a user’s device and hence the best form of defense in this case is to have token theft detection in place and enable users to revoke all their sessions (across devices). SuperTokens detects theft and enables revocation of all refresh and access tokens for that user (enabling them to logout of all devices at once).
There are several ways an attacker can get access to your database or file system (injection attacks, physical server access or mismanaged employee access controls). With database access, hackers could get hold of currently active auth tokens or the JWT / SSL private key.
Consequence: Potentially all users and all information
- Supertokens stores only the hashed value of user’s authentication tokens - thereby preventing an attacker from being able to use the tokens.
- Supertokens allows for frequent renewal of the JWT signing key without logging any user out ( see how we do this By changing the signing key - all current access tokens are invalidated. This would generally cause users to be logged out but with our implementation, the client (frontend) would use the refresh token to request for a new access token. ).
If an application provides access / refresh tokens to other apps via OAuth, then there is a risk of the main app’s auth tokens being stolen if the other app’s servers are compromised. For reference, see the recent docker hub case study.
Consequence: Potential leak of information of all users on both your platform and the compromised platform.
Mitigation: Prevention of this type of attack is not possible. The best solution is to have short lived access tokens, enable them to be instantly revoked and enable theft detection. SuperTokens provides all of this.
Consequence: Single user account compromised but potentially many accounts compromised depending on the attack
This attack is not used to steal auth tokens — instead, it allows an attacker to piggyback on an existing active session (read more here).
Consequence: Compromised single user account, but potentially many accounts too.
Mitigation: Prevention of CSRF attacks typically requires the use of an anti-CSRF tokens. SuperTokens provides CSRF protection by combining it with authentication calls.
This is possible either when HTTP is being used, HTTPS is incorrectly implemented or when all traffic is flowing through a malicious proxy (i.e. many organisations and more recently - the entire country of Kazakhistan does this).
Consequence: Single account compromised
Mitigation: Developers must use Https and ensure correct implementation for all their API endpoints. As mentioned, SuperTokens uses secure cookies. SuperTokens also reduces the frequency of transit of critical auth tokens (refresh tokens) and this can be modified by the developer by changing the expiry time of the access token. In the future, we may add fixed public / private keys per device which further prevents MITM attacks to only the first instance of transmission.
An attacker with sufficient resources can incessantly ‘guess’ auth tokens until one of their attempts proves successful. This would provide them with all the access the stolen token confers.
Consequence: Single user account compromised or potentially more
Mitigation: SuperTokens generates long auth tokens with high entropy making brute force attacks impossible for non state actors. Furthermore, the constant changes in access and refresh tokens make this attack even more improbable.
This occurs when a non logged in user, logs in to your app, but their auth token values do not change.
Consequence: Single user
Mitigation: The best way to solve this is to generate a new set of auth tokens each time a user logs in and to invalidate the old ones if any. This is done per device and not per user. SuperTokens forces the generation of a brand new session each time a user logs in. In the future, we will add support for carrying forward session data from an old session to a new one.
Session theft detection
SuperTokens makes it possible to detect if a user’s tokens have been stolen!
The official OAuth 2.0 specifications, by the IETF (Internet Engineering Task Force), explicitly states that applications should detect token theft through the use of rotating refresh tokens. The RFC document and relevant section can be found here and an excerpt is below:
This is something that SuperToken implements taking into account all the network issues, race conditions and edge cases while ensuring scalability. This is a non trivial problem that Fitbit attempted to solve in the past (Source). The above also explains how refresh token rotation enables detection of theft. However, for a more detailed illustration, please see
An attacker has managed to acquire the victim’s refresh token — RT0. Upon expiry of the access token (AT0), both the victim and the attacker would be required to use RT0 to acquire a new set of tokens.
If the attacker uses RT0 first, then they will receive a new RT1 and AT1, which when used, will invalidate RT0. When the victim uses the invalidated RT0, the server would receive a clear indication that theft has occurred since the client should have used RT1. A similar argument works if the victim uses RT0 first.
If both, the victim and the attacker, use RT0 at the same time, then one would get (RT1, AT1), and the other (RT2, AT2). The next request by either of them with the new access token would either invalidate RT1 or RT2, resulting in either the victim or the attacker to be logged out. Again, here the backend would get a clear indication of theft .
The video shows a demonstration of a site that uses SuperTokens and a site that does not. In the site that does not use SuperTokens, the attacker and victim remain logged in after token theft has occurred, where as in with SuperTokens, the theft is detected and both users are logged out - preventing wrongful access to user information.
Easy to use and understand
SuperTokens uses functions that are intuitive and have been designed for flexibility. Users may build on top of existing functions. With the way SuperTokens is written, developers can customize the library without having to change or even completely understand the library code. For example, if you want to allow just one user to be logged into exactly one device. This can be achieved fairly easily just using the functions we provide.
We spend an equal amount of time on documentation as we do on our source code as we know that good documentation is core to a good developer experience. We strive to keep our documentation complete, easy to follow and up to date. For example, see SuperToken documentation for node and mysql here.
Users of SuperTokens have many of the benefits of open source:
Battle tested: Developers from all across the world with varying use cases have successfully implemented SuperTokens and we have been in contact with them to sort out any issues in the library. The power of crowdsourcing enables more thorough detection and addressal of bugs. We’ve also used this library for an extended period of time in our own application - Qually.
Auditability: Developers can go through the entire codebase if they like and verify for themselves all the claims mentioned in this document
Support: We have a quickly growing community where people can ask and answer each other questions. However, we also provide dedicated support and assist developers with implementation, customisation and provide an in depth understanding of the code. If you are interested in dedicated support - contact us.
SuperTokens manages all of the following:
- Cookie handling and storing session data securely
- Synchronisation issues across multiple servers
- Race conditions, network and server failures. For example, we deal with situations where the new issued tokens may not reach the frontend, a race condition involving multiple tabs on a single browser and more - right off the bat.
- Supertokens has been designed with scalability in mind. It’s ready to scale when you are.
- It has everything you would expect from a session management library - including efficient blacklisting of JWT access tokens, revoking sessions, retrieving userIDs from a session and refreshing sessions.
Long lived sessions
Long lived access tokens are great for the user experience but not good for security. Short lived sessions are great for security but are frustrating for the user and bad for your business metrics! With Supertokens, we enable users to have long lived sessions without compromising on security.
Keep your users logged in indefinitely - saving them from the frustration of having to remember their password.
Optimal Time and space complexity
Even with all these features, our space requirement in your database is equivalent to any other session management library. That is, we store only one row per logged in user per device! Given this, we make token theft detection possible by using our proprietary parent-child hierarchy algorithm when creating auth tokens. See pseudo code for our session management here.
In terms of time complexity, we encourage the use of short lived JWT access tokens, this means, we do not need to perform a database query for most authentication calls! This really makes a difference as you scale.
Prevents unwanted data scraping
Due to our handling of session tokens, it is vastly more complex to build a scraping bot for services that use SuperTokens.
Going beyond - feature extensibility
Supertokens can be upgraded to HyperTokens - our paid enterprise version, at any time in the future. HyperTokens has additional functionality that could be useful in other areas. Some examples of features that hyper tokens provides - session management for multiple database instances (necessary as you scale), a developer analytics dashboard (API time and reliability performance, resource strain), quicker token theft detection and more. For a full list - see here.
Is this all really possible? Yes. We’ve put our heart and souls into building the best and most optimised solution for session management out there. If there is any reason at all you could think for not using this library - let us know in the comments below! If your reason is generally applicable to most user session flows, you can have a $50 Amazon gift card on us. We’re serious.