[echelon]

I worked for two years on a session system for an institution that cared deeply about security.

We had to trace, kill, kill all for single or multiple sessions, users, or organizations. Do this for entire IP ranges, client versions, or client ids. Rate limit all "session-mutating" (unidirectional state machine) actions, time out, model session confidence, restrict session scopes (subset authz), associate with any entity written or touched, monitor lists of compromised emails and passwords, require 2fa...

Your opinions might work where money and privacy aren't involved. But I wouldn't trust your posture with my bank info, emails, or personal messages.

What happens if your signing key leaks? Or you accidentally log session JWTs? Or someone's device goes missing, or someone steals a password, or an account manager has their info posted openly?

We're not worried about just our entire database. We're worried about any ATO, undesired action, or data leak, however small. Even one impacted person is too many.

Security really fucking matters. Take it seriously or don't touch it.

[cphoover]

I don't get why you couldn't have a panic bit set the same way you maintain an in memory revocation leak... Also I don't get how this is any different than "what if a DB password" leaks?

What if someone steals a device and copies the httpOnly cookies from the network developer inspector tab then forges the requests using Curl?

I don't see how these problems are unique to JWTs and how they exist unmitigated with the use of in-memory revocation list.