https://stackoverflow.com/questions/14682153/lifetime-of-ker...
Ed: Note that the service doing the renewal won't need the user/password - only a way to check if the user is blacklisted, as well as a way to sign/make tokens - and doesn't have to be the same system that issues the initial token.
Obviously the renewal service would need to be able to sign the new/extended token.
1. The shorter the lifetime, the more JWTs and refreshes are needed. This includes the signing and verification, both of which can be heavy operations depending on key length.
2. Token introspection is a coupling hub and spoke. If every service needs to introspect every JWT, it will be coupled to the introspect API. While that isn't horrible in some cases, it can be a nightmare in others. Additionally, new services need to always remember to use this pattern. You can get around this with an API gateway though. In either case, the introspection API either needs to store all the JWTs (in memory or a database) to determine if they have been revoked, or use some other mechanism to determine revocation. If you have large numbers of JWTs valid at any time, this doesn't scale well.
3. This is basically the same as my approach. It sounds like you are using a distributed cache. I'm using Webhooks and multiple local caches. Basically the same thing if your Webhooks are written properly.
But agreed, webooks in general are not excellent for critical events in general unless there are additional ways and of confirming receipt and confirmation.
1. shorter lifetimes with no other revocation system. This works well if you go back to a central party which has the actual business logic/state to decide whether to issue a new token
2. token introspection API, possibly with caching to reduce network calls/user latency
3. API-based blacklist with invalidated token identifiers (either JTI or SID)
In the first two approaches you are trying to prevent state from being pushed out to the apps at the edges.
The third approach is what I took with Distributed Token Validity API, which was basically a distributed system (via state replication or fetch + cache) to move the minimal state needed as close to the app as feasible.