Even if the cookie size limit was 8192 bytes instead of 4096, I think it's insane to include a several KB signature on every request over the network (literally worth multiple packets). It's not a big deal if the payload is a large media file, but JWTs are most commonly used in the kind of API requests where the body is often empty or something tiny like {"success": true}. It'd be a shame to undo all the wins from things like smaller TLS handshakes using ECDSA (more of a pleasant side effect, but still).
This is good for browsers which do a ton of requests to the same resource. It's less useful for service-oriented architecture where services would more often talk to other services through an LB, often contacting different nodes.
Are you regularly using stateless, asymmetrically-encrypted tokens during service-to-service communication? That strikes me as a rather odd architecture decision, but maybe there's something I'm missing.
We are doing this and it works pretty great across a bunch of microservices.
A user makes a call into a gateway, which talks to the identity service to get a JWT with info about who the user is. Now the gateway passes the call on to the microservice being referenced and it gets the users basic access info with no extra calls, and better it can call any other internal service and continue to pass along the token.
Well, the question was about how often is it used, not how well it serves the purpose. So I'd say pretty often.
Having a data storage accessible for every service that needs authentication and authorization (and ideally every service needs at least authentication) is non trivial in distributed enterprise environment. To have a stateful token, you need to have a distributed scalable storage, unless you have only one instance. You need to be able to connect to it, hence distribute and manage database password. Anything symmetric requires a more sophisticated secret management.
