0

I understand why one shouldn't store the contents of the JWT token client-side but what about just storing the token expiration time?

I'm using the auth0 authentication service in my app and I'd like to save the tokenExpiry value to localstorage. From a security standpoint, is this considered bad practice?

  • If the server is going to be checking this value, then it's probably not safe; otherwise, I don't see a problem. – multithr3at3d May 13 at 22:40
  • @multithr3at3d How would the server check a client-stored value (unless the client also sent it to the server at some point, which would not happen automatically)? Why would the server even use that value, when the validity period of the JWT is stored within the JWT itself? – CBHacking May 14 at 2:12
  • @CBHacking exactly, just making sure it wasn't being used in a weird way. – multithr3at3d May 14 at 21:07
4

First of all, storing the JWT client-side is not only acceptable, it is mandatory; your client can't make authenticated requests if it doesn't have its session token. You can store it different places, each with their own security tradeoffs (a cookie is traditional, and can be hidden from script with the httponly flag, but also needs to use the secure flag and puts you at risk of CSRF and similar if you don't use the samesite flag or your browser doesn't support it yet; persistent or session local storage won't be sent automatically the way cookies are and can protect against CSRF, but an XSS payload could steal them). It can be stored ephemerally (session storage or session cookies, although realistically, people often don't actually close their browsers these days) or persistently (its lifetime should be short enough, and included in the signed data of the token and therefore immutable, that this is probably safe but pointless). It's gotta be stored, though.

With that said, even if the token is stored in an httponly cookie (where script can't see it), there's no harm in storing the token's expiration time in local storage. I'm not sure what you plan to do with this data (warn the user when their session is running out? Submit a refresh token request?) but there's no security impact to doing so.

EDIT: A bit more background

JWTs include their expiration time / validity lifetime within themselves, in a portion that is cryptographically signed. Only the server can generate a valid signature, and if any of the signed data (including the expiry) is tampered with, the signature becomes invalid. A JWT with an invalid signature cannot be used (the server will reject it). The server will also reject a JWT that has expired, of course, so the server neither cares what the client thinks the expiration is, nor should ever ask anything except the JWT itself (including its timestamp and signature) whether it is currently valid.

  • Your assumption is correct. I'm planning to warn the user that their session is running out. So the expiration time must only be stored in a place where the script doesn't have access to it (e.g a httponly cookie), not in a localStorage variables, right? – kingJulian May 14 at 1:17
  • 1
    To quote myself: "... there's no harm in storing the token's expiration time in local storage... there's no security impact to doing so." – CBHacking May 14 at 2:09
  • 2
    Upvoted, though judging by OP's comments you could possibly improve the answer by explaining the role of the signature that makes it such that you can't just write in your own expiration value. – AlphaD May 14 at 6:06
  • Upvoted too and agree with @AlphaD. Such an explanation would help a lot. – kingJulian May 14 at 7:50
  • Thanks for your update @CBHacking. However if I understand your update correct, if someone alters the expiration value in local storage and there's a client-side check based on expiration, then there will be a security breach. Correct? – kingJulian May 15 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.