Application Security – JavaScript Web Tokens

JavaScript web tokens are well documented and are used for authentication. JWT’s consist of three parts; the header, payload and signature. The header is used to describe the JWT, specifically, it will indicate how the signature is calculated. The payload of the JWT will contain claims about the user presenting the JWT, claims are just another word for attributes. There are a few predesignated claims there should be included in your JWT, other claims can be free form, that means the payload can contain any data that the developer wants it to contain. The signature is used to prevent tampering of the JWT.  The most common signing algorithms are HS256, RS256, and ES256, however, there are other algorithms.  One of the most important claims that should always exist in the payload is the “exp” claim. The “exp” claim represents the epoch time that the JWT will expire, without this claim the JWT is valid forever.

The expiration claim on the JWT introduces an interesting issue with session management, when a user intentionally terminates a session, how do you invalidate the JWT?  A common design pattern that I see on application tests is for the client-side application to receive a JWT from the server and then store it in the browser’s session storage. Subsequent Ajax requests will include the JWT as a bearer token in the authorization header.  When a user intentionally terminates a session, otherwise known as logging out, the application will simply delete the JWT from the browser’s session storage. This has the effect of causing the browser to believe the session was terminated because the application can no longer authenticate to the server since the application can no longer find the JWT in the session store.  However, this is an illusion, deleting the JWT from the session store does nothing to invalidate the session, the deleted JWT will remain valid until the expiration date has been reached. If an attacker had captured the JWT, they would be able to use it until the exp claim lapses.  This type of session handling runs afoul of the OWASP best practices, OWASP states that a secure session termination requires at least the following components.

• Availability of user interface controls that allow the user to manually log out.
• Session termination after a given amount of time without activity (session timeout).
• Proper invalidation of server-side session state.

This leaves the developer with the before mentioned question, how can a JWT be invalidated when the user logs out?  One solution that I have heard is to have short lived expirations and to use a refresh token to re-issue the JWT upon expiration.  While this solution limits the window in which an abandoned session could be used, it doesn’t actually solve the problem.  I have seen a few other recommendations that should work in theory, but they are not always practical or easy to implement. Below I describe the easiest method that I have found.  It makes changes to how developers generate JWT signing keys and how they create, verify, and terminate sessions.