Add HMAC Signature Authentication to your APIs to establish the identity of the consumer. The plugin will check for valid signature in the Proxy-Authorization and Authorization header (in this order). This plugin implementation follows the draft-cavage-http-signatures-00 draft with slightly changed signature scheme.


Configuring the plugin is straightforward, you can add it on top of an API by executing the following request on your Kong server:

$ curl -X POST http://kong:8001/apis/{api}/plugins \
    --data "name=hmac-auth"

api: The id or name of the API that this plugin configuration will target

You can also apply it for every API using the http://kong:8001/plugins/ endpoint. Read the Plugin Reference for more information.

form parameter default description
name The name of the plugin to use, in this case: hmac-auth
false An optional boolean value telling the plugin to hide the credential to the upstream API server. It will be removed by Kong before proxying the request
300 Clock Skew in seconds to prevent replay attacks.


In order to use the plugin, you first need to create a consumer to associate one or more credentials to. The Consumer represents a developer using the final service/API.

Create a Consumer

You need to associate a credential to an existing Consumer object, that represents a user consuming the API. To create a Consumer you can execute the following request:

curl -d "username=user123&custom_id=SOME_CUSTOM_ID" http://kong:8001/consumers/
parameter description
The username of the consumer. Either this field or custom_id must be specified.
A custom identifier used to map the consumer to another database. Either this field or username must be specified.

A Consumer can have many credentials.

Create a Credential

You can provision new username/password credentials by making the following HTTP request:

$ curl -X POST http://kong:8001/consumers/{consumer}/hmac-auth \
    --data "username=bob" \
    --data "secret=secret456"

consumer: The id or username property of the Consumer entity to associate the credentials to.

form parameter description
username The username to use in the HMAC Signature verification
The secret to use in the HMAC Signature verification

Signature Authentication Scheme

The client is expected to send an Authorization header with the following parameterization:

credentials := "hmac" params
params := keyId "," algorithm ", " headers ", " signature
keyId := "username" "=" plain-string
algorithm := "algorithm" "=" DQUOTE (hmac-sha1) DQUOTE
headers := "headers" "=" plain-string
signature := "signature" "=" plain-string
plain-string   = DQUOTE *( %x20-21 / %x23-5B / %x5D-7E ) DQUOTE

Signature Parameters

parameter description
username The username of the credential
algorithm Digital signature algorithm used to create signature, only hmac-sha1 is supported
headers List of HTTP header names, separated by a single space character, used to sign the request
signature Base64 encoded digital signature generated by the client

Signature String Construction

In order to generate the string that is signed with a key, the client MUST take the values of each HTTP header specified by headers in the order they appear.

  1. If the header name is not request-line then append the lowercased header name followed with an ASCII colon : and an ASCII space .

  2. If the header name is request-line then appened the HTTP request line, otherwise append the header value.

  3. If value is not the last value then append an ASCII newline \n. The string MUST NOT include a trailing ASCII newline.

Clock Skew

The HMAC Authentication plugin also implements a clock skew check as described in the specification to prevent replay attacks. By default, a minimum lag of 300s in either direction (past/future) is allowed. Any request with a higher or lower date value will be rejected. The length of the clock skew can be edited through the plugin's configuration by setting clock_skew property (config.clock_skew POST parameters).

The server and requesting client should be synchronized with NTP and a valid date (using GMT format) should be sent with either the X-Date or Date header.

HMAC Example

For an HMAC signature with date and content-md5 headers, the Proxy-Authorization or Authorization header and signature would be generated as:

Authorization: hmac username="bob", algorithm="hmac-sha1", headers="date content-md5", signature="Base64(HMAC-SHA1(signing string))"

The client would compose the signing string as:

date: Fri, 09 Oct 2015 00:00:00 GMT\ncontent-md5: lCMsW4/JJy9vc6HjbraPzw==

Upstream Headers

When a client has been authenticated, the plugin will append some headers to the request before proxying it to the upstream API/Microservice, so that you can identify the consumer in your code:

  • X-Consumer-ID, the ID of the Consumer on Kong
  • X-Consumer-Custom-ID, the custom_id of the Consumer (if set)
  • X-Consumer-Username, the username of the Consumer (if set)
  • X-Credential-Username, the username of the Credential

You can use this information on your side to implement additional logic. You can use the X-Consumer-ID value to query the Kong Admin API and retrieve more information about the Consumer.