The 1st case would require to generate for each communication a HMAC identifying the request, so the server can re-generate it to make sure the client is authorized (because the HMAC is encryped with a private key that is only known by the server and the client), while the 2nd one only requires the service to issue the certificate (or token) once, and keep it live for some minutes -ex. 15 minutes-. Of course to prevent MITM or Replay attacks it must be sent only over SSL, with all the conseguences (more bandwitdh and more CPU requirements).

Personally I find the 1st to be not only simpler but also stronger, because each request has its own unique data, while the 2nd relies on the SSL certificate integrity (I'm not saying that's easy to crack a signed SSL certificate, but if someone would break it all the traffic would be sniffed for all communications).

So I find them to have the following pro/cons:

* HMAC pros: unique token for each request, can be really secure against MITM and Replay attacks -by using unique data to compose the signature and a timestamp-, easy to implement
* HMAC cons: requires the server to work for each single request to re-generate the token
* Token pro: one token for multiple requests, useful on services that require multiple client actions
* Token cons: requires SSL for all communications.

I think I'd need to set up some tests to get a final answer, but I'd love to hear if someone has already some knowledge or some tought based on old experiences.