Public signature of challenges as authentication Assuming you trust a client's public signature keys, a simple authentication protocol would be to send a long random string challenge, and get the client to sign it
Since most of authentication still relies on more sophisticated protocols like sending some form of secret over the tubes and verifying it in the server, there must be some weaknesses in the above protocol that I am ignoring.
What issues is there with this approach? If you rely on HTTPS to send the challenge, most MitM attack surface is removed, am I correct?
What issues is there with this approach?

There are both theoretical and practical concerns with this kind of solution.
First, it is generally not seen as a good idea these days to just sign whatever the somebody else handed you, especially if you also use the signing key in other contexts. This is to prevent an attacker from sending you a &quot;challenge&quot; like &quot;you, lurscher, authorize a wire transfer to me, SEJPM, with a value of 10k USD&quot; and then me presenting this to your bank. There are ways to fix this problem though.
The more practical concerns though are usually more important in this context. Namely: Most servers simply don't have have a public key they are sure is associated with a given user. And if they do, how long do you think it will take until users start complaining or loosing their private keys? Using good old static authenticators (like passwords) is simpler. Additionally, from a server's perspective there is typically very little extra security gained from such an involved authentication strategy. You already assuming a secure channel after all and I can't think of a scenario right now where standard password transmission over HTTPS with server-side (basic) hashing would be significantly more secure than a public-key based solution (in a web context).
Outside of web contexts, yes, authenticating both parties with a public key is a viable strategy which is why TLS has built-in support to do so.