The most secure and easy to implement solution for user session management
This is part 2 in a two-part series on session management. If the reader understands the general concepts of JWT (JSON web token) and user sessions, then Part 2 can be read without reading Part 1.
Part 2: Analysis of a new open source session flow that is secure and easy to integrate
Part 1 provided an educational guide into session management (how auth tokens are handled, stored and changed during an active session) and we discussed several commonly employed session flows. However, we believe that the flows mentioned in Part 1 are sub-optimum in terms of security for most use cases. We came across a flow conceptualized by the IETF (Internet Engineering Task Force) in RFC 6819. We’ve taken the proposed flow, built it and upon request of others, have open sourced our code for the wider community.
In this post, we’ll explore and analyze the session flow, talk through some implementation details and provide you with a customizable library. The library is production ready and can be integrated with your system in under a day (currently available for NodeJS and MySQL).
Rotating refresh tokens with short-lived access tokens
The critical auth token is perpetually exposed over two attack surfaces, the frontend, and the backend and occasionally exposed over transit.
Effect of stolen auth tokens:
Access token stolen: The attacker will have unauthorised access for a short period of time (until token expiry)
Refresh token stolen: Detection of theft will enable the stolen refresh token to be invalidated, limiting the damage to a short period of time
Detection of theft:
Access token stolen: This theft may only be detected through the use of heuristic algorithms or if the user notifies the provider / developer of the service.
Refresh token stolen: Detection of theft will be possible as long as both the attacker and victim use the refresh token at least once post the attack. This is illustrated through an example below.
Access tokens need not be revoked since they are short lived. However, if needed, Opaque access tokens can be revoked by removing them from the database.
Refresh tokens can be revoked easily by removing it from the database.
That summarizes the discussion of the conceptual flow. Below, are some additional pointers to keep in mind for readers that would like to implement this flow on their own. Alternatively, we have an open source implementation of this flow available on Github.
That concludes the bulk of the matter we have on session management. Below you will find a GitHub repository with the source code that deals with all of the implementation issues. It is highly customizable to your requirements and can be quickly integrated into your system. It is also very secure in terms of prevention and detection of token theft. We’d love to know what you think of it — please do leave a comment or email us.
As long as the library is alive — we promise to support it (fix bugs, address issues, add features and update documentation) and be responsive (via SO, email etc).
To show some additional love to our early readers, we’re offering the following dedicated support:
Dedicated support will only be free till the 10th of July 2019!
If you refer others to the library (anyone who contributes to or uses the library), we will provide you and that person an additional month of free dedicated support beyond July. The more people, the more support (up to 6 months maximum). Refer to the Git readme to see more details regarding this.
Building a production-ready session management solution is nontrivial. It requires deep knowledge and is expensive in terms of time and money. Many developers do not prioritize session management — leading to suboptimal, unsecured systems in production.
We’ve discussed various session flows in these two posts. Depending on the requirements, one flow might be better suited than the others. In general, our recommendation would be the following:
For services that deal with very sensitive data (eg: a stock trading platform or something like Ashley Madison), security may take precedence over user experience. The ideal flow would be a combination of session flow 3 and session flow 4 from part 1. Specifically, use short-lived access tokens whose active usage will extend expiry for some finite amount of time. However, this would require users to re-login when tokens expire — which could happen often.
For all other services, the flow mentioned above is likely to be appropriate. Within this, the use of JWT access tokens is recommended (for easier scalability). However, if it’s important that access tokens be instantly revokable, then use Opaque access tokens. Additionally, security can be improved through the use of 2-factor authentication or passwordless login methods. The latter has the benefit of not requiring users to remember yet another password.
And that’s it! Please do let us know what you thought while reading this through the comments or by emailing us here. We hope this was useful.
 If using opaque token, then immediate logout, else they would be logged out after the expiry time of their new JWT.
 This is a race condition problem: Let’s say a user has opened your app in Tab1 and Tab2 in their browser. Both these tabs share the same set of cookies. The following illustration demonstrates how a race condition can lead to user logouts.
Level up your reading game by joining Hacker Noon now!