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.


  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?



1 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.

  • relying on HTTPS protects current session from tampering but what if a token has been stolen in previous session and now attacker tries to impersonate caller, wouldn’t HMAC prevent such attack? Commented Aug 3, 2020 at 20:04
  • why does stripe sign their webhooks then stripe.com/docs/webhooks/signatures ? also github signs it’s webhooks Commented Aug 3, 2020 at 20:05
  • Signed requests can also provide ephemeral and isolated authentication. If you add other factors (e.g., time and service_endpoint) to your signing function, your service host(s) never need long-lived password/key information distributed locally. Services can just ask your auth service for a list of the valid intermediate ephemeral tokens.
    – svidgen
    Commented Aug 3, 2020 at 21:09
  • “what if a token has been stolen in previous session”: if HTTPS is compromised, you have more important things to think of than some benefits of HMAC. Likewise, if your PC, or the server, is compromised, HMAC or not, you're screwed anyway. Commented Aug 3, 2020 at 22:21
  • “why does stripe sign their webhooks then”: HMAC is indeed often used in WebHooks, probably (1) because of the inverted mode of communication, (2) and because of the fact that HTTPS is not guaranteed. I would also imagine that either an RFC recommended it (although I haven't checked), or just one company did it, and others copied it. Anyway, if I remember well, one of Amazon's services also used (or maybe still uses) a sort of HMAC; but this doesn't mean it is still useful or necessary. Commented Aug 3, 2020 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.