Jiffy applications do not direct support the revocation or automatic renewal of JWT tokens. Instead, a cross-process cache of User information is maintained via a group-membership service. The service ensures that changes to User information (create/update/delete) are disseminated to all running instances of the Jiffy generated application. Consequently, in Jiffy-based applications it makes sense to discuss User access revocation from the perspective of an administrator making a call to the user-API to perform general User deletion or deactivation. Such changes are affected in the backend database, and then updated in the application server caches by way of the web-sockets-based group-membership service.
Conditions
Revocation Steps
Revocation Results
These steps are the same whether a user is being disabled, being granted more access, or having access to certain services revoked.
Jiffy application JWTs contain a standard set of registered claims as outlined in RFC7519 . Login to a jiffy generated application results in the creation of a new JWT where the standard ‘exp’ claim is set based on the value of the ‘jwt_lifetime’ key in the application’s configuration file. When the current (server) date-time exceeds the value contained in a JWT’s ‘exp’ claim, the token is no longer accepted by the application. After JWT expiration, the used is forced to login again.
It would be possible to alter the Jiffy application to create self-renewing JWT’s. Doing so would mandate that the client developer compare the Authorization field in the response header to the one that was sent in the request. For now, the strategy is to have the application configuration set a JWT validity of ~12 hours, and then force the user to login again once the time limit expires.
On one hand, this approach to (not supporting) JWT renewal means that the client/consumer of the RESTful services need not worry about checking the JWT content at the end of each exchange. On the other hand, the current strategy may be a concern in system-to-system interfaces especially where it is not acceptable to set a very long JWT expiry limit in the configuration.