JsonWebToken: activity-based expiration vs issuing time-based expiration

Question

I'm fairly new to token based authorization. I'm trying to find the flaws in a custom expiration/token-refresh scheme.

I have a basic JWT auth setup in an Express API; I'm setting the JWT expiration to 1 hr; However, JWT checks token expiration relative to the time the token was issued. I would prefer that the expiration time gets reset after each successful api call. If my user is actively using the app for more than an hour, I don't want them to have to log back in to refresh the token (and possibly lose whatever data they are working on.)

On the the other hand, I do want the token to expire if they are not responsive for more than an hour.

I have come up with the following approach:

During every successful API request, issue a new JWT and send it in a custom response header. My client side code is responsible for checking this JWT response header and using its value as the new default Authorization request header. Thus, if there is no API request from the user for more than 1 hour, the token will expire and not be refreshed. Login would then be required. In addition, the original issue-date of the token (timestamp of login-authentication) will be stored so that a "hard-expiration" of the token will be enforced after 24 hours.

This seems fairly straightforward and reasonably secure, but I haven't seen any reference to it in my JWT research. Is there a better way to achieve the same goal? Am I missing a major security hole with this approach?

UPDATE: After thinking of this for some time, I realized that the problem with this is that it opens the door to replay attacks that could not be thwarted by token expiration. So there should absolutely be a "hard-expiration" check: hard expiration would invalidate the token at some time after issue date, regardless of recent user activity.

Answer 1

Here you can check my answer for this scenario: implementing refresh-tokens with angular and express-jwt

What I have done is to have a time window where the server checks if the token expiration and the local server time is in this window and then send a response header with the refreshed token.

Answer 2

If you agree and realize that you need a hard expiry time anyhow, why not set the expiry time of the (one and only) access token to that and stick to plain OAuth 2.0? An asymptote of what you're doing now, would be to issue your own API specific token/cookie after first use of the access token (in the API response) and enforce subsequent API access based on that. That is a valid approach, but duplicates a lot of stock OAuth 2.0 Authorization Server functionality in your own API. I don't see a good reason to go there.