[alexk]

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.

[still_grokking]

I still don't get the difference.

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.

[vladvasiliu]

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.

[xyzzy123]

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.

[danappelxx]

Right! Which is why we use (public) short-lived JWTs and (private) long-lived refresh tokens. What’s missing?