JWT or public-private keys for service to service API calls

The JWT was created to handle a wide range of situations (differentiated claims, separate identity server, many users, etc.). Your situation is fairly straight forward - you have only one client (A) that needs to communicate with one server (B).

You could handle this case with JWT if you want to, but there is no need too. It would indeed be overkill, since the JWT requires some form of authentication in the first step. And if you have to set that up, why not use it all the way through? The private-public key setup you suggest would work equally well. So unless you expect your requirements to change, I would go with the one that is simpler to implement.

Something very similar to your suggestion is actually already implemented in TLS, namely client authentication. In that setup, the client has to provide a certificate to the server for authentication. You might want to look into that.

You sort of point to it, using JWT access tokens in an Oauth infrastructure, with a proper authorization server (AS) is the standardized way to do it. It gives you standard ways to tune access later, through a central service. And it scales well.

Your solution is probably secure on a small scale, if you don't need to give many users or other services access. You need to deal with key management, which could just as securely be a symmetric key.

That would make this something like Github's webhook protocol: https://developer.github.com/webhooks/

This uses a HMAC header on the request.