In reality, this does not happen all the time. Most system to system interactions won't probably need this feature.
When this feature is needed it does become complex to handle this requirement efficiently. I have seen one implementation of this requirement in the past that was particularly clever and effective. It did use Redis with local client cache. It did work very well and had very little overhead because every revoked token was kept in Redis only until the token itself reached its own invalidity time (in that case was 1 week). Also, in this particular setup, the cardinality of the revoked keys was very low (in the order of less than a hundred at a given time). Therefore it was very feasible to keep a local copy of the list of currently revoked keys and use Redis pub/sub to keep those local copies in sync. Not really stateless but it did minimise the number of requests to the auth server significantly!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a very valid point, thanks @xazzzi
In reality, this does not happen all the time. Most system to system interactions won't probably need this feature.
When this feature is needed it does become complex to handle this requirement efficiently. I have seen one implementation of this requirement in the past that was particularly clever and effective. It did use Redis with local client cache. It did work very well and had very little overhead because every revoked token was kept in Redis only until the token itself reached its own invalidity time (in that case was 1 week). Also, in this particular setup, the cardinality of the revoked keys was very low (in the order of less than a hundred at a given time). Therefore it was very feasible to keep a local copy of the list of currently revoked keys and use Redis pub/sub to keep those local copies in sync. Not really stateless but it did minimise the number of requests to the auth server significantly!