Add Key Authentication (also sometimes referred to as an API key) to a Service or a Route (or the deprecated API entity). Consumers then add their key either in a querystring parameter or a header to authenticate their requests.


  • plugin: a plugin executing actions inside Kong before or after a request has been proxied to the upstream API.
  • Service: the Kong entity representing an external upstream API or microservice.
  • Route: the Kong entity representing a way to map downstream requests to upstream services.
  • upstream service: this refers to your own API/service sitting behind Kong, to which client requests are forwarded.
  • API: a legacy entity used to represent your upstream services. Deprecated in favor of Services since 0.13.0.


Enabling the plugin on a Service

Configure this plugin on a Service by making the following request:

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=key-auth" 
  • service: the id or name of the Service that this plugin configuration will target.

Enabling the plugin on a Route

Configure this plugin on a Route with:

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=key-auth" 
  • route_id: the id of the Route that this plugin configuration will target.

Enabling the plugin on an API

If you are using an older version of Kong with the legacy API entity (deprecated since 0.13.0), you can configure this plugin on top of such an API by making the following request:

$ curl -X POST http://kong:8001/apis/{api}/plugins \
    --data "name=key-auth" 
  • api: either id or name of the API that this plugin configuration will target.

Global plugins

All plugins can be configured using the http://kong:8001/plugins/ endpoint. A plugin which is not associated to any Service, Route or Consumer (or API, if you are using an older version of Kong) is considered "global", and will be run on every request. Read the Plugin Reference and the Plugin Precedence sections for more information.


Here's a list of all the parameters which can be used in this plugin's configuration:

form parameterdefaultdescription
nameThe name of the plugin to use, in this case key-auth
service_idThe id of the Service which this plugin will target.
route_idThe id of the Route which this plugin will target.
enabledtrueWhether this plugin will be applied.
api_idThe id of the API which this plugin will target. Note: The API Entity is deprecated since Kong 0.13.0.


Describes an array of comma separated parameter names where the plugin will look for a key. The client must send the authentication key in one of those key names, and the plugin will try to read the credential from a header or the querystring parameter with the same name.
note: the key names may only contain [a-z], [A-Z], [0-9], [_] and [-].



If enabled, the plugin will read the request body (if said request has one and its MIME type is supported) and try to find the key in it. Supported MIME types are application/www-form-urlencoded, application/json, and multipart/form-data.



An optional boolean value telling the plugin to show or hide the credential from the upstream service. If true, the plugin will strip the credential from the request (i.e. the header or querystring containing the key) before proxying it.


An optional string (consumer uuid) value to use as an "anonymous" consumer if authentication fails. If empty (default), the request will fail with an authentication failure 4xx. Please note that this value must refer to the Consumer id attribute which is internal to Kong, and not its custom_id.



A boolean value that indicates whether the plugin should run (and try to authenticate) on OPTIONS preflight requests, if set to false then OPTIONS requests will always be allowed.

Note that, according to their respective specifications, HTTP header names are treated as case insensitive, while HTTP query string parameter names are treated as case sensitive. Kong follows these specifications as designed, meaning that the key_names configuration values will be treated differently when searching the request header fields, versus searching the query string. Administrators are advised against defining case-sensitive key_names values when expecting the authorization keys to be sent in the request headers.

The option `config.run_on_preflight` is only available from version `0.11.1` and later

Once applied, any user with a valid credential can access the Service/API. To restrict usage to only some of the authenticated users, also add the ACL plugin (not covered here) and create whitelist or blacklist groups of users.


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 upstream service.

Create a Consumer

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

$ curl -X POST http://kong:8001/consumers/ \
    --data "username=<USERNAME>" \
    --data "custom_id=<CUSTOM_ID>"
HTTP/1.1 201 Created

    "custom_id": "<CUSTOM_ID>",
    "created_at": 1472604384000,
    "id": "7f853474-7b70-439d-ad59-2481a0a9a904"
parameter default 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.

If you are also using the ACL plugin and whitelists with this service, you must add the new consumer to a whitelisted group. See ACL: Associating Consumers for details.

Create a Key

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

$ curl -X POST http://kong:8001/consumers/{consumer}/key-auth -d ''
HTTP/1.1 201 Created

    "consumer_id": "876bf719-8f18-4ce5-cc9f-5b5af6c36007",
    "created_at": 1443371053000,
    "id": "62a7d3b7-b995-49f9-c9c8-bac4d781fb59",
    "key": "62eb165c070a41d5c1b58d9d3d725ca1"
  • consumer: The id or username property of the Consumer entity to associate the credentials to.
form parameter default description
You can optionally set your own unique key to authenticate the client. If missing, the plugin will generate one.
Note: It is recommended to let Kong auto-generate the key. Only specify it yourself if you are migrating an existing system to Kong. You must re-use your keys to make the migration to Kong transparent to your Consumers.

Using the Key

Simply make a request with the key as a querystring parameter:

$ curl http://kong:8000/{proxy path}?apikey=<some_key>

Or in a header:

$ curl http://kong:8000/{proxy path} \
    -H 'apikey: <some_key>'

Delete a Key

You can delete an API Key by making the following HTTP request:

$ curl -X DELETE http://kong:8001/consumers/{consumer}/key-auth/{id}
HTTP/1.1 204 No Content
  • consumer: The id or username property of the Consumer entity to associate the credentials to.
  • id: The id attribute of the key credential object.

Upstream Headers

When a client has been authenticated, the plugin will append some headers to the request before proxying it to the upstream service, 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 (only if the consumer is not the 'anonymous' consumer)
  • X-Anonymous-Consumer, will be set to true when authentication failed, and the 'anonymous' consumer was set instead.

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.

Paginate through keys

Note: This endpoint was introduced in Kong 0.11.2.

You can paginate through the API keys for all Consumers using the following request:

$ curl -X GET http://kong:8001/key-auths


You can filter the list using the following query parameters:

Attributes Description
A filter on the list based on the key-auth credential id field.
A filter on the list based on the key-auth credential key field.
A filter on the list based on the key-auth credential consumer_id field.
optional, default is 100
A limit on the number of objects to be returned.
A cursor used for pagination. offset is an object identifier that defines a place in the list.

Retrieve the Consumer associated with a key

Note: This endpoint was introduced in Kong 0.11.2.

It is possible to retrieve a Consumer associated with an API Key using the following request:

curl -X GET http://kong:8001/key-auths/{key or id}/consumer

  • key or id: The id or key property of the API key for which to get the associated Consumer.

Keep up with the latest features