Consider if a malicious actor is able to fool the client into using http instead of https, or is able to sign arbitrary certs, because they control a CA that is trusted by the client (as in some corporate firewalls for example, or malware installed a bad CA). Now the client sends the auth token as part of the request, the MitM can intercept it, and get the auth token, and the server has no way of knowing there is a third party involved.
But with a client cert, intercepting the request gets you nothing. You don't have the secret key, so there isn't any way for you to complete the TLD handshake with the server.
> The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know.
No, the server doesn't need to know the privkey at all, it only needs to know the public key of the CA that signed the cert.
The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know.
Certificate-based authentication and token do protect equally from MITM. And MITM attacks are equally possible when cert or token auth is being done.
The only thing where cert based auth got the client shines is that you don't have to move a new token over the wire, initially.