Force long lived JWT access tokens that are not expected to be used
often/quickly to check to revocation like a refresh token.

For example consider a third party time tracking application with a JWT. It hits the
REST/web interface when the user changes tasks. Compare to a WT used by an alternate
front end written in react where all the data (20/30 or more requests/sec) for a
page is obtained via the REST interface.

For the third party infrequent use case, consider adding something to the JWT to trigger
checking to see if the JWT has been revoked.

This does destroy the statelessness of the JWT. However it shouldn't be any worse
than the stateful checks done with a refresh JWT.

A refresh JWT should be identifiable by the payload: either a role: (e.g. jwt:refresh)
or a refresh claim. All Refresh JWT's should be checked for revocation.
Using a claim to identify the refresh token might be better than a role. With the claim,
could the role be used as a template to simplify generation of the new JWT access token?
I.E. The only difference between the access token and the refresh token is the refresh claim.
So minting a new access token is copying the Refresh token, removing the refresh claim
and resetting the iat (issue time/not valid before) and exp (expiration time) claims.