The JWT and authentication
Recent readings about the use of JWT in authentication headers, their refreshing, and so forth raised some recent concerns and questions . While some articles regarding JWT and state session management suggests neither storing in local storage of the token, disabling the token via state session variable across browser tabs seems reasonable enough. For instance, having event listener arranged on change of this variable facilitates the removal of the token within web app, and the auth token isn’t directly stored.
As to generating refresh tokens with something like page reloading is another problem. For general web app usage access, which omits anything but general and not restricted (sensitive) usage access, this appears fine, but auth tokens which are user specific and sensitive to the nature of higher level account access, a generalized (non user) based JWT refresh token is an option. The user will likely be prompted anyways again for login credentials (restricted level access). This suggests forgoing the refresh token unless again for all other reasons excepting. This also begs the question in web app development is the refresh token, otherwise, needed mostly given the likelihood that internal state refreshing methods existing anyways reducing the proclivity of a user resorting to hit the ‘reload’ button?
The circularity of this problem is that generating a higher level authentication JWT likely requires local storage without more complex methods of verifying clearly a user that could be verified with authentication prompting, and dealing with all the security headaches of possible token theft. Chances are a lot of users probably won’t resort to the “reload” button, and resolution of this seems more to convenience of users that have a habit of doing just that which is probably a smaller subset of users today relative the past.
My suggestion is that outside of any number of handlings (complex or otherwise), added security vulnerability exists with the refresh token if it is not handled properly. Secondly auth API side server data management is an added factor (tracking issued tokens) potentially. In memory JWT storage better as I’ve read, and refreshing easier to do in these instances, but the reload erasing of memory and subsequent refresh token is another matter. Lastly even if a session state variable regarding logout event handling were disrupted, it seems there are server side ways to remedy around these problems, but the auth token remains hidden. Final notes, I’ve read popularly used passport authentication deals with session state security vulnerabilities for its own internal reasons and one should wonder local storage is the culprit. Wise things to consider for session state management…