The following comes with a (big) grain of salt, because my knowledge of JWT is only theoretical, but I am trying to give a helpful answer:
You have a login process in which the credentials are checked and - based on business rules - the user is or is not allowed to log in; perhaps he was banned etc. As a positive result this user is getting a token in return, which has an issuing date as well as an expiry date; in case of a negative result the user gets - of course - no new token. The token he got authenticates the user for as long as the expiry allows. So there might be a gap between the point in time, you do not want the user to use your service and the point in time when the valid token expires.
A viable solution would be to propagate the information that tokens for a given user before a given point in time are invalid. This information has to be stored at the according servive as long as the given token is itself isn't expired:
Say your tokens live for two hours, this information could be discarded after two hours. So you prevent littering your "bad tokens"-table.
If the user visits your site before the expiry, the token is thrown as immediately away as the information is propagated through your system.
If he tries to log in, he doesn't get a fresh token; the same goes of course for the refresh option.
I need to know if the user is not logged in [...] admin gets a list of users -> admin selects one user to deactivate -> the server checks if the user to be deactivated is not logged in -> if it is, don't deactivate and return an error to admin, else, deactivate and return success to admin.
What is the background for that?
Update: Every time a user logs in a new token is generated. There is a logout option, it blacklists the user's token so that it can't be used again.
Is there a reason for "blacklisting" a token instead of rendering it useless with an expiry date in the past and throwing a token away?
What information do you store in your token, if any?