This is where my opinion may slightly differ from the blog posts you cited. Keep in mind that my experience is more consumer-like vs e.g. a financial institutio

This is where my opinion may slightly differ from the blog posts you cited. Keep in mind that my experience is more consumer-like vs e.g. a financial institution, so requirements may be different based on your application. The main question is: assuming you detect a weird case, are you going to conservatively log out the user or risk that an attacker might be taking over the account? I'm for the latter, of course under the assumption that auth is not your last line of defense, but you'll monitor the user/attacker activity and block the account if you think it's an attack. If I were to build a financial app, I'd definitely opt for the former. My other assumption/experience is that storage is cheap, so you should store (a reference to) all valid tokens. Revoke is then done by marking the record as revoked and/or delete the record. Now, when the resource service receives an authenticated call, you can either: 1. Check the token against the "list of all tokens" storage (likely exposed by the auth service). Or, 2. Trust that the token hasn't been revoked before expiration. One way you can achieve 2) is for example to have your frontend to periodically pull the auth service and either receive a refreshed token, or get the cookie cleared out.