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.
- 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
|The Service that this plugin configuration will target. Required.
|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
|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:
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:
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.
|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:
Run on Preflight
|Indicates whether the plugin should run (and try to authenticate) on
OPTIONS preflight requests. Default:
Generate a Credential
Generate a Client ID credential to use as an API key. You can generate multiple
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.
Scroll to view all of the available examples.
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
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
Response (will be the same for all valid requests regardless of key location):
Make a request with the key in the body
key_in_body parameter must be set to