2

I am working on React-Django application that uses JWT for authentication. The user signs in with their username and password, the server validates and responds with JWT and username, and (currently) I am only storing the JWT in sessionStorage.

That JWT is then verified as being valid and current anytime the user navigates between protected routes. If it is still good, it is refreshed. i.e. It is sent from sessionStorage.getItem('token') to the server, a new one is sent back if the sent one is still valid, and replaces the existing one in sessionStorage. Cool.

The problem I am have run into is while I have identified the user is allowed to access, and continue accessing, these protected routes, I don't really know who they are and therefore am unable to pull data that is specific to them. (I haven't had luck with using stuff like user = request.user.username to gather who the current user is and the JWT after the initial issue of the JWT doesn't carry username along with it... from what I can tell.)

So I see two options to resolve this:

1) Store the JWT in the DB with relationship to the user and in sessionStorage so that it can be called from sessionStorage, compared against the DB, and then identify the user from that.

It seems like this might be the "safest" option to go.

2) Since the server is already sending back the username along with the JWT when the user logs in, I can just start storing both in sessionStorage. That way, I can sessionStorage.getItem('username') and requests to the server to retrieve user specific information. However, someone could sessionStorage and get their username. (The JWT's are only good for 15 minutes, and if it meets that time limit, the user is logged out, and sessionStorage.clear() is done.)

The second one, is what I am concerned about security-wise. I am far from being a security expert, so just curious what the ramifications of storing username in sessionStorage is and which of these would be "better".

EDIT: As I continue to read on the subject, I'm finding numerous guides and books that use examples where username is stored in sessionStorage. That doesn't make it right though. For example, this lovely example storing username and password in localStorage (I might be going out on a limb here, but that is a really bad idea):

https://www.daniweb.com/digital-media/ui-ux-design/threads/476533/login-and-registration-using-local-storage

cjones
  • 223
  • 2
  • 7
  • Store the username in the JWT. That's part of there purpose anyway. – TrickyDupes Nov 10 '17 at 18:04
  • if someone is in sessionStorage already, the user has far bigger problems. in short, it's not your responsibility as a site operator to ensure pristine clients; assume the worst. – dandavis Nov 10 '17 at 18:50

1 Answers1

1

Well done for thinking through the limitations of JWT. Most people don't and, as you've seen, most of the JWT tutorials on the web are horribly insecure.

One thing to note is that the delivery of a JWT to the server does not demonstrate that the originating device/browser is the one that was given the token in the first place. That is one reason JWT's should be very short lived because on their own, they are easily subject to token replay attacks. Even TLS does not guarantee freedom from a JWT replay attack - if the original PC was already compromised.

To add extra security, you need to be sure you need it. Obviously one of the reasons for using JWT is to lighten the load on the server. Adding server-side token validation and/or a session store clearly removes some of that advantage.

If you do need the extra security, you will either need to encrypt extra data into the token - e.g. ip address. Or you will need to store enough data in a session store to be able to sensibly validate that the token has come back from where you expected it to, again perhaps recording the originating IP address.

A session store is arguably more secure but probably not by much.

Your question regarding identity is easily resolved by storing the userid against the token in your session store if you are using one. If you decide you don't want additional security, then it is enough to store the id in the token as long as the token values are encrypted on the server.

Julian Knight
  • 7,092
  • 17
  • 23