Yes, I like this approach and it creates the opportunity for a hybrid approach between stateless JWT tokens and stateful sessions: * JWT tokens can have a "sho

Yes, I like this approach and it creates the opportunity for a hybrid approach between stateless JWT tokens and stateful sessions: * JWT tokens can have a "short" expiration time, as you suggest, and within that time can be used in a stateless manner -- i.e. they do not need to be validated against a central session store, etc. * The refresh token process can use a more traditional session type configuration, where the token is checked against a central session store. The refresh can be refused if the central "session" has been revoked, e.g. This to me gives you all the benefits of JWT (e.g. you can use federated authentication services) and the benefits of a centralized session store (e.g. easy revocability). The main concern would be if you needed more "immediate" revocability within the stateless time frame. One solution would be to implement a "blacklist" that holds a temporary list of revoked tokens (and a token only needs to live on that list for as long as its expiration window). Alternatively, at that point you could just stick to a traditional session.