Sure, but that's the nuclear option. Imagine if Facebook did that every time one account was compromised or they fired a staffer?

Facebook as the largest userbase of any application in existence. Its needs may not equate to your needs. For example, an enterprise b2b app with a few hundred customers could probably "deal with" the nuclear option.

Man I'm not sure I agree with that. Blowing up a bunch of your clients that rely on your services randomly because one account was compromised is not acceptable for really any professional business regardless of the number of clients.

"Blowing them up" is a mischaracterization of the situation. You are not mutating their data. You're only asking them to login again.

Actually blowing them up is a completely appropriate description if you have any non-human's relying on JWTs.

Applications that use authenticated services need to handle being the authentication being revoked. That's fairly obvious regardless of how it happens. If your app doesn't then it's broken.

I'd be pretty upset if I got kicked out of a work app every time one of a few hundred companies fired someone (or even had to do a password reset for a security reason).

A multi-tenant system could use a different key-pair for each tenant and only revoke the one for the compromised entity

The issue is not remembering the password.

The issue is I just logged in 90 seconds ago, typed up a few paragraphs, and when I go to submit I have to do it again, because someone in another company using the tool got phished and needs a new password.

It's frustrating enough when Gmail makes me put my password in after 30 days and I just clicked into an email I wanted to read. Having it happen all day long would make me want to kill someone.

I wasn't suggesting mutating the signing key multiple times per day or once per 90 seconds. At that point, you might as well just have a very early JWT expiration timestamp specified.

The comment thread started with "if you need them to be revocable". Any tool with "a few hundred [enterprise] customers" needs to be able to revoke access for terminated employees, compromised accounts, and the like, and those revocations will occur frequently and in many cases need to have immediate impact.

So now every user has to log back in again every time you upgrade your server, simply changing the signing key or when your backend gets compromised.

Additionally JWEs don't support forward-secrecy meaning that I can MITM and collect all JWEs passing through, find the key in your compromised backend and decrypt ALL these collected tokens.

No need to do this with JWTs since they're unencrypted by default.

Your server shouldn't be getting compromised on a regular basis. The occasional black swan event occurs, and sometimes you have no other choice.

Users get compromised though and will want to revoke sessions. But this is why you just set a time limit on your JWT, so that they can revoke and within N minutes the old sessions will die. Just keep N low.