I'm implementing my JWT method by using the double submit method: where we separate the payload & header portion of the JWT from the signature.

The header & payload is stored in a separate cookie, not HttpOnly so its accessible by the client, and the signature is HttpOnly.

The implementation seems pretty straight forward, but I'm having an issue understanding how refresh works.

For example, since I'm using firebase, the users jwt token has an expiration of 1 hour. When that expires, we need to automatically refresh the token, but this means we are refreshing the whole token. The whole point of the signature token is to be session long.

How can we refresh just the payload & header part of the token, without it affecting the signature?

The strategy I am using is based on this article: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3

1 Answer 1


What you are trying to accomplish does not work based on the JWT specification. Let's focus on the relevant part (taken from JWT.io), the scope of the signature:

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

You sign the header and the payload. According to RFC 7519, the payload contains the "exp" claim, which defines the expiration time.

This means, if you want to refresh the token, you have to change the expiration time. This changes a value that is signed. Therefore, the signature must also change, otherwise it doesn't validate the rest of the token.

Long story short, you cannot change the expiration time without changing the signature

EDIT: Based on the source of this method, one crucial information was missing in the original question.

My answer above is still correct, if you implement JWT expiration with the "exp" claim. The linked method sets the "exp" to a full day (see chapter "Other Important JWT Payload Content"), thereby avoiding an actual token timeout. When the token (containing header and payload) gets refreshed, they do not change the content at all, but they only change the expiration date of the cookie. That way, the token stays the same and the signature stays valid.

So your issue is setting the "exp" claim to 1 hour instead of 1 day as suggested in the article.

  • I came across the method here: medium.com/lightrail/… How are they able to implement this technique?
    – alex067
    Commented Mar 5, 2020 at 20:03
  • @alex067 - Oh, I see what they did there! They implemented the expiration based on the cookie lifetime and not on the "exp" claim in the JWT token. It would be a good idea to link this article in the question itself for better understanding. I will update my answer based on that knowledge.
    – Demento
    Commented Mar 5, 2020 at 20:26
  • 1
    @alex067 you should now that this is a terrible idea. If you ignore the expiration in the token and instead rely on the expiration of the cookie, then you are making a permanent JWT. This is because a JWT (usually) cannot be revoked, which is why it has a short lifetime. If it also cannot expire then it lives forever and whoever steals it gets permanent access as the end user. Of course the actual user will lose access when the cookie expires, but if an attacker steals it, it no longer lives in a cookie and so will never expire. Commented Aug 2, 2020 at 21:26
  • 1
    As a result there is very little point in this whole "set cookie expiration for an hour and then reset it for longer as needed". This completely breaks the main security controls in a JWT. Commented Aug 2, 2020 at 21:28
  • 1
    Therefore this answer is completely correct: what you are trying to do simply is not possible in the JWT specification. Commented Aug 2, 2020 at 21:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .