I stumble across this in trying to help someone on another forum and the answers here give information about client certificates that is, at best, misleading if not incorrect.
First things first.
What is a client certificate?
A client certificate is (in typical parlance) an X.509 certificate like the one that let's your browser trust this website. What makes it a 'client' certificate is that it was signed by the certificate authority for the purpose of "Client Authentication (22.214.171.124.126.96.36.199.2)"
In other words, the CA has confirmed the certificate for that use. It's otherwise like a server certificate in all other ways. In fact, a single certificate can be signed for both "Server Authentication (188.8.131.52.184.108.40.206.1)" and client authentication.
Does sending a certificate potentially compromise it?
No! Click on the little lock next to the URI in your browser and look at the certificate. Have you compromised stack exchange? Not in the slightest. Certificates are inherently public. They contain no secrets.
In either a certificate authentication scenario (client or server) it's the possession of the private key that is considered proof of identity. If your private key is leaked, you have an problem. This is true whether this is a client or a server certificate.
In the process of authenticating with a certificate (server or client), no secrets from the private keys are exchanged. They are also immune to replay attacks which is something you need to consider when using JWTs.
What if I have different roles?
Aside from what it can be used for, client certificates are generally not used to confer authorization. They establish identity. How that identity is mapped to rights is a separate issue.
Why aren't client-certificates used much for client authentication?
Mainly because creating, signing, and, managing a private key securely is beyond most users. I think this could change as physical secret management components become more common.
When are client-certificates a good option?
When you have robust PKI in place. Additionally, I think it's important to have a good handle on, at least, the basics of public-key security. For instance, if you are running a web-server that needs to act as a client in web-service interactions. If you already have a server certificate to manage, there's not much more additional overhead to managing a client-certificate as well (or using a single certificate for both.)
In this scenario, there's also no user around to type in a password or show their face or swipe a finger. It's probably running on a rack in some server farm. How are you going to authenticate this host to the third-party to generate a token? If you are using a password or other secret that you are continually sending in order to get a token, I question the wisdom of approach.
Ideally you would have some sort of HSM which stores the secret and never exposes it externally. That kind of approach is become more common and affordable.