HTTP(S) API authentication: why not many services require signing (HMAC)?

Question

I am currently researching existing authentication/authorization solution that are used for REST APIs. More specifically I'm interested in backend-to-backend interactions but client-to-backend is relevant too.

I looked at few existing solutions and how existing services manage this. It looks like in many cases using JWT tokens is de-facto a standard path. Some services chose other approaches which are fine too. However what confuses me is why not many places require usage of MAC (message authentication digest) to authenticate payload of a request? Existing solutions either rely on a secret simply being attached to every request or sent once in a while to be exchanged to JWT.

Examples:

1. auth0 offers to send client secret within body of a request to token grant endpoint: https://auth0.com/blog/using-m2m-authorization/

   POST https://<YOUR_AUTH0_DOMAIN>/oauth/token
   Content-Type: application/json
   {
     "audience": "<API_IDENTIFIER>",
     "grant_type": "client_credentials",
     "client_id": "<YOUR_CLIENT_ID>",
     "client_secret": "<YOUR_CLIENT_SECRET>"
   }
   

2. Stripe's api: https://stripe.com/docs/api they also using bearer approach and rely on HTTP basic auth to provide secret token to endpoints.

3. In this article: https://blog.restcase.com/4-most-used-rest-api-authentication-methods/ it's stated:

   The previous versions of this spec, OAuth 1.0 and 1.0a, were much more complicated than OAuth 2.0. The biggest change in the latest version is that it’s no longer required to sign each call with a keyed hash.[ ...]

Section 7.1 of OAuth2 framework https://www.rfc-editor.org/rfc/rfc6749#section-7.1 is allowing MAC type of a token but it doesn't seem to be too be used anywhere.

So I've got few questions:

Why is this happening? Is it just a way to simplify things? Are we now in the place where it is possible to completely rely on security provided by TLS and assume that it's impossible to steal secret or tamper with the data? Or is it just not always reasonable to employ such solutions? Is there some kind of a questionnaire one needs to answer to evaluate necessity of requiring signed requests?

Thanks!

Answer 1

When communicating with a web server, you may be interested in:

• Guaranteeing that you're actually communicating with the server, not somebody who pretends to be that server.

• Encrypting your communications. It's not of the business of your ISP what you store to Amazon S3 or what text messages you send through Twilio.

• Ensuring your request or the response from the server weren't tampered, i.e. what is received is exactly what was sent: no change of information, nothing appended to it, and nothing removed from it.

• Avoiding replay attacks, i.e. when somebody records your request, and performs it again later on.

HMAC solves only one of those needs, more exactly the third one, but does nothing to address the other three. Instead, HTTPS addresses all four. There are simply no valid cases where you would be concerned about tampering, but wouldn't care at all who are you communicating with, who's listening in the middle and how many times the requests you do are repeated.

Why not combining HTTPS and HMAC? The thing is, nothing is free. If you add layers for the sake of security, you should really be sure they bring a benefit which outweighs the cost of extra complexity, extra development, extra testing, extra debugging. Especially in terms of security, your code should be as simple as possible.

So why, you may ask, HMACs exist in the first place? Well, there are other means of communication where they make sense, such as communication between two electronic devices which simply don't have the computing power to use TLS and no ability to keep track of certificates.