Short version is that with mTLS and short-lived certificates you don't have to worry about anyone stealing and re-using your JWT tokens and revoking tokens.
LVH from Latacora explains it way better than I could in "A child's garden of inter-service authentication" [1]
However, here is my view:
If your token is not bound to the connection, someone can steal and reuse it, just like any other token. It is possible to use OAuth token binding [2], but at this level of complexity, mTLS + short lived certs deliver the same security and are easier to deploy.
It's easy to mess up JWT signatures, although, to be fair, it's not like X.509 certificates format is any better, however it's been more tested over years of use.
Interesting. You already don’t have to worry about revoking JWTs if they’re sufficiently short lived. This gives you the exact level of protection as a short-lived mTLS cert, because if that gets stolen the attacker can continue to establish connections until it expires, unless as you say you revoke the certificate. So clearly I am missing something.
They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service.
With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expires.
If someone steals your secrets you're screwed. No matter what kind of secrets that are. That's clear.
But if you keep your secrets in a HSM (TPM, SmartCard, …) and only use them to derive session keys directly on the secure device there is absolutely no difference which concrete tech you're using (given that secure cryptography is in place).
mTLS is a great approach, no question. But I just don't see how it's more secure than any other public key crypto.
If I'm not mistaken, the difference is that in the case of JWT, your app manipulates the secret directly, so it must show up in clear form somewhere, from the app's perspective.
So, if the app host is compromised, the attacker shouldn't have too hard a time to extract the JWT and use it from somewhere else.
In contrast, with an HSM, the attacker would need to have the HSM sign any new connection attempt, which should be a bit more involved if it happens on a different machine.
mTLS tends to add infrastructure complexity, I much prefer it when you can "terminate" auth where you like in the ingress path for user-facing stuff rather than first-hop auth.
I wish there were "real" standards and a better ecosystem for request signing.
LVH from Latacora explains it way better than I could in "A child's garden of inter-service authentication" [1]
However, here is my view:
If your token is not bound to the connection, someone can steal and reuse it, just like any other token. It is possible to use OAuth token binding [2], but at this level of complexity, mTLS + short lived certs deliver the same security and are easier to deploy.
It's easy to mess up JWT signatures, although, to be fair, it's not like X.509 certificates format is any better, however it's been more tested over years of use.
[1] https://latacora.micro.blog/2018/06/12/a-childs-garden.html [2] https://connect2id.com/learn/token-binding