This is a good article! fusionauth looks cool =)<p>Here are some things to consider though (I work on this problem a lotttt):<p>1. Do you (as the app developer) really care about security that much? If not, just go with local validation on your JWTs and understand that there is a window of time, whatever your token lifetime is, that you will be at risk for compromise and abuse. If you do care, continue down the list, if not, just don't worry about it.<p>2. So you care about security, yey! Now, your problem is this: what level of risk are you OK with? If you're ok with NO risk, continue reading. Otherwise: set your JWT expiration time to the amount of risk you're ok with. EG: 1 minute, 5 minute, 1 hour, 1 day, etc.<p>3. OK! So you're REALLY serious about security and want no risk. Now we're talking! You really only have one choice: validate your JWTs centrally to ensure that a user hasn't been deleted, token revoked, etc. But now you have to decide the best way to do this! Here are your options:<p>A) You can validate tokens centrally on every request with the IdP: this is basically the same thing as normal old session management: you check the session against a DB to validate it.<p>B) You create a cache of tokens that are blacklisted (aka: a blacklist), so that you can do an O(1) lookup to see if a token is expired. The only problem? This is usually centralized, too! So no real benefit over option (A) except that it's a bit quicker (if you don't make mistakes w/ cache invalidation, etc.).<p>C) You do what this article talks about: you distribute your blacklist directly to your edges: one way to do this is with webhooks, websockets, or really just about any method of syncing data between places. This is a great approach, but unfortunately, a lot more can go wrong: what if your webhook doesn't get processed quickly enough? What if your client breaks and stops being able to accept webhooks? What if the webhook server stops firing or gets overloaded?<p>In my personal opinion, (A) is the best choice, because it's the simplest, the hardest to get wrong, and can always be cached to speed things up. The only problem with (A)? The only problem is that if you're doing it this way, why use a JWT at all? Why not just use a normal old cryptographically signed session ID? Not much benefit, IMO.