1

We currently have a stateless REST api, authenticated by JWT bearer tokens. (each of our servers trust the incoming JWT token as long as it's unexpired, load the user, and auth using the loaded user.)

We currently store the JWT token in localstorage, for development convenience. However, we're starting to implement security and defences, and we want to change our implementation. So:

  1. We're going to send the JWT token as an HTTPonly and secure cookie (incidentally, this means that we don't have to manage it on the client side Javascript, because, well, we can't.)

  2. We're going to include a CSRF token in our JWT response.

A couple of questions:

  1. Introducing CSRF introduces state to our system, in that we're going to have to share this token across all our servers. While not being a stateless purist, this does bother me a little. Are there other ways of dealing with this?

  2. Should we change the CSRF token each time? It seems like there's still 30 mins (our timeout setting) worth of vulnerability if we don't. However, if we do, does this introduce timing issues with pages that would make multiple API calls?

Jeff Wang
  • 1,837
  • 1
  • 15
  • 29
  • What is the reason for using CSRF with JWT? – jsalonen Jun 20 '17 at 21:22
  • because storing the JWT in local storage is vulnerable to XSS, and sending it in a cookie is vulnerable to CSRF. see https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication – Jeff Wang Jun 20 '17 at 21:25

0 Answers0