Hawk Autentication considered harmful.

I was asked recently to add support for Hawk to sabre/http. It kinda seemed like a fun addition, but I’m building an increasing grudge, up to a point where I’ve nearly lost interest.

Missing documentation

The documentation is incomplete. The author points to his own javascript-based implementation as the reference, but 1700 lines of javascript code is simply not as easy to read as a plain-english reference.

In addition, the version of the protocol (currently 2.0) appears to be locked to the javascript library, and not the actual protocol.

This means that if bugs get fixed in the javascript source, the protocol version gets a bump. Leaving us no way to figure out something changed in the protocol, unless you’re willing to go through the diffs for the source.

Uses the used hostname and port as part of the signed string

The both the hostname and the port are part of the signed string, unlike alternatives like AWS authentication and Digest.

The only case where this would actually be relevant, is if there’s two endpoints with identical urls, and re-uses the same keys and secrets, and a identical request on the same url would be unwanted.

The drawback is that many service don’t know what url was originally being used by a client, due to the use of reverse proxies.

Now we’re forced to create a mechanism where the reverse proxy sends the original host header to the client.

Could have built upon Digest auth

Digest has a lot of good things going for it, and has a great deal of overlap in features.

Hawks strengths here are that it uses a stronger hash algorithm (hmac-sha256) and unlike Digest, it there’s no need for pre-flighted requests to discover the service nonce. The latter is also the author’s main concern with using Digest instead, as stated in the FAQ.

An answer to that would have been rather simple though. Any server could simply hardcode and document their server-side nonce, rendering the initial negotiation optional, but still possible.

Furthermore, digest can be easily extended with new algoritms.

What to use instead?

I’d highly recommend using simply either HTTP Digest, or if you’re looking for something a little bit more fancy, use Amazon’s authentication header.

Some benefits:

  • They are tried and tested for many years.
  • Not a moving target.
  • Documented.
  • Easier to implement.
  • Have lots of sample implementations.

That being said, I will probably still add support to an upcoming version of sabre/http.

Web mentions


  • MeadSteve

    Hey. Good article. However the HTTP Digest and Amazon auth links are swapped over. Which early on a Monday morning took me way too long to realize why I was so confused.

    • Evert


      Fixed! Only 10 months later :)

  • philsturgeon

    As I'm sure you know, Hawk is being built by Erin Hammer to produce and improved OAuth 1.0, after he fell out of love with OAuth 2.0. It could be interesting to hear more comparisons to OAuth 1 or 2 in an update or follow-up. :)

    • Evert


      The overlap with Hawk and OAuth1, is that Hawk fulfills the '2 legged authentication' piece of OAuth1, but not the 3-legged version. 2-legged auth in OAuth1 was always a bit of a poor fit, so from a pure technical standpoint. Hawk does that better.

      Most of my concerns with Hawk are not at all technically btw, they're all really communication and stability problems. OAuth1 does not have those issues. It actually made it into an rfc, which I see as a great indicator of stability:

  • Jonas

    It's interesting though that AWS signature version 4, does include host...

    With everything hosted behind load balancers that does HTTPS, finding the real hostname from proxy headers can be somewhat tricky...

  • nickshanks

    Also, two years later, there's still a typo in the title.