You are browsing documentation for an older version. See the latest documentation here.

Enable Key Authentication for Application Registration

You can use the Key Authentication plugin for authentication in conjunction with the Application Registration plugin.

The key auth plugin uses the same Client ID as generated for the Kong OAuth2 plugin. You can use the same Client ID credential for a Service that has the OAuth2 plugin enabled.

Prerequisites

Create a Service.
Enable the Application Registration plugin on a Service.
Activate your application for a Service if you have not already done so. The Service Contract must be approved by an Admin if auto approve is not enabled.
Generate a credential if you don’t want to use the default credential initially created for you.

Enable Key Authentication in Kong Manager

In Kong Manager, access the Service for which you want to enable key authentication for use with application registration:

From your Workspace, in the left navigation pane, go to API Gateway > Services.
On the Services page, select the Service and click View.
In the Plugins pane in the Services page, click Add a Plugin.
On the Add New Plugin page in the Authentication section, find the Key Authentication Plugin and click Enable.
Complete the fields as appropriate for your application. In this example, the Service is already prepopulated. Refer to the parameters described in the next section, Key Authentication Configuration Parameters, to complete the fields.
Click Create.

Key Authentication Configuration Parameters

Form Parameter	Description
`Service`	The Service that this plugin configuration will target. Required.
`Anonymous`	An optional string (Consumer UUID) value to use as an anonymous Consumer if authentication fails. If empty (default), the request fails with an `4xx`. Note that this value must refer to the Consumer `id` attribute that is internal to Kong, and not its `custom_id`.
`Hide Credentials`	Whether to show or hide the credential from the Upstream service. If `true`, the plugin strips the credential from the request (i.e., the header, query string, or request body containing the key) before proxying it. Default: `false`.
`Key in Body`	If enabled, the plugin reads the request body (if said request has one and its MIME type is supported) and tries to find the key in it. Supported MIME types: `application/www-form-urlencoded`, `application/json`, and `multipart/form-data`. Default: `false`.
`Key in Header`	If enabled (default), the plugin reads the request header and tries to find the key in it. Default: true.
`Key in Query`	If enabled (default), the plugin reads the query parameter in the request and tries to find the key in it. Default: true.
`Key Names`	Describes an array of 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, request body, or query string parameter with the same name. The key names may only contain [a-z], [A-Z], [0-9], [_] underscore, and [-] hyphen. Required. Default: `apikey`.
`Run on Preflight`	Indicates whether the plugin should run (and try to authenticate) on `OPTIONS` preflight requests. Default: `true`.

Generate a Credential

Generate a Client ID credential to use as an API key. You can generate multiple credentials.

In the Dev Portal > My Apps page, click View for an application.
In the Authentication pane, click Generate Credential.

Now you can make requests using the Client ID as an API Key.

Make Requests with an API Key (Client Identifier)

The Client ID of your credentials can be used as an API key to make authenticated requests to a Service.

Tip: You can also access key request instructions directly within the user interface from the information icon in the Services details area of your application. Click the i icon to open the Service Details page.

Services Pane

Scroll to view all of the available examples.

Service Details Page Embedded Key Usage Instructions

About API Key Locations in a Request

Use cases for key locations:

Recommended: Use key_in_header (enabled by default) as the most common and secure way to do service-to-service calls.
If you need to share links to browser clients, use key_in_query (enabled by default). Note that query parameter requests can appear within application logs and URL browser bars, which expose the API key.
If you are sending a form with a browser, such as a login form, use key_in_body. This option is set to false by default because it’s a less common use case, and is a more expensive and less performant HTTP request.

For better security, only enable the key locations that you need to use.

Make a request with the key as a query string parameter

      cURL
    
      HTTPie
    
curl -X POST {proxy}/{route}?apikey={CLIENT_ID}
http {proxy}/{route}?apikey={CLIENT_ID}

Response (will be the same for all valid requests regardless of key location):

HTTP/1.1 200 OK
...

Make a request with the key in a header

      cURL
    

      HTTPie
    
curl -X POST {proxy}/{route} \
--header "apikey: {CLIENT_ID}"
http {proxy}/{route} apikey:{CLIENT_ID}

Make a request with the key in the body

      cURL
    

      HTTPie
    
curl -X POST {proxy}/{route} \
--data "apikey:={CLIENT_ID}"
http {proxy}/{route} apikey={CLIENT_ID}

Note: The key_in_body parameter must be set to true.