> Common workarounds like maintaining a blacklist of revoked tokens introduce statefulness, negating the benefits of JWTs.
> Validation: On each request, we validate the JWT's signature using the application secret and then validate the sjti using the user's secret.
Having to lookup the user secret from the db is no different than consulting a list of revoked tokens. You claim consulting a list of revoked tokens to be stateful. How is looking up the user secret different?
"which we'd likely do anyway for authorization checks". Assuming you are using a session token, authentication != authorization. You will eventually hit your authorization logic to check if the user can perform action X. It may just be through claims in the token, but I don't think most are doing that. So you will eventually pull user data and you can to this check there if you are passing the token through context.
I have been using this for a while, and I haven't managed a revocation list, I haven't done user queries at the boundary and users are able to logout and instantly invalidate their JWT. I honestly haven't seen this elsewhere without overhead.