[geezerjay]

> You can still revoke JWTs if you give them an ID and keep a revoke list somewhere.

You don't need the ID. You can simply store the token's signature. In fact, some implementations store the whole JWT to avoid roundtrips to the auth service, and revoking the token is just a matter of flipping an attribute in the database.

[jondubois]

This kind of comment might make one wonder why not just use a sessionId to begin with but JWT in this case is still useful in a microservice arch because a token which has been revoked from one high security microservice may still be valid for lower security microservices: It gives each microservice the option of deciding what kind of security they need to provide... They may not need any revocation list; maybe the JWT on its own is sufficient; they just keep accepting the token until it expires naturally.

The token expiry determines the baseline accuracy of banning across all services.

[geezerjay]

> This kind of comment might make one wonder why not just use a sessionId to begin with

JWT and sessionIds are totally different beasts. JWT are used per request, are designed to expire and be refreshed, are specific to each individual endpoint and store authorization info in a specialized third party service.