Add Key Authentication (also sometimes referred to as an API key) to a Service or a Route. Consumers then add their key either in a querystring parameter or a header to authenticate their requests.
Terminology
plugin
: a plugin executing actions inside IAM before or after a request has been proxied to the upstream API.Service
: the IAM entity representing an external upstream API or microservice.Route
: the IAM entity representing a way to map downstream requests to upstream services.upstream service
: this refers to your own API/service sitting behind IAM, to which client requests are forwarded.
Configuration
This plugin is compatible with requests with the following protocols:
http
https
This plugin is partially compatible with DB-less mode.
Consumers and Credentials can be created with declarative configuration. Admin API endpoints which do POST, PUT, PATCH or DELETE on Credentials are not available on DB-less mode.Enabling the plugin on a Service
With a database
Configure this plugin on a Service by making the following request:
$ curl -X POST http://localhost:8001/services/{service}/plugins \
--data "name=key-auth"
Without a database
Configure this plugin on a Service by adding this section do your declarative configuration file:
plugins:
- name: key-auth
service: {service}
config:
In both cases, {service}
is the id
or name
of the Service that this plugin configuration will target.
Enabling the plugin on a Route
With a database
Configure this plugin on a Route with:
$ curl -X POST http://localhost:8001/routes/{route}/plugins \
--data "name=key-auth"
Without a database
Configure this plugin on a Route by adding this section do your declarative configuration file:
plugins:
- name: key-auth
route: {route}
config:
In both cases, {route}
is the id
or name
of the Route that this plugin configuration will target.
Global plugins
- Using a database, all plugins can be configured using the
http://localhost:8001/plugins/
endpoint. - Without a database, all plugins can be configured via the
plugins:
entry on the declarative configuration file.
A plugin which is not associated to any Service, Route or Consumer (or API, if you are using an older version of IAM) is considered "global", and will be run on every request. Read the Plugin Reference and the Plugin Precedence sections for more information.
Parameters
Here's a list of all the parameters which can be used in this plugin's configuration:
form parameter | description |
---|---|
name | The name of the plugin to use, in this case key-auth |
service_id | The id of the Service which this plugin will target. |
route_id | The id of the Route which this plugin will target. |
enabled default value: true | Whether this plugin will be applied. |
config.key_names
optional default value:
|
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 or the querystring parameter with the same name. |
config.key_in_body
optional default value:
|
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 |
config.hide_credentials
optional default value:
|
An optional boolean value telling the plugin to show or hide the credential from the upstream service. If |
config.anonymous
optional |
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 |
config.run_on_preflight
optional default value:
|
A boolean value that indicates whether the plugin should run (and try to authenticate) on |
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. IAM 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.
Once applied, any user with a valid credential can access the Service. 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.
Usage
Create a Consumer
You need to associate a credential to an existing Consumer object. A Consumer can have many credentials.
With a Database
To create a Consumer, you can execute the following request:
curl -d "username=user123&custom_id=SOME_CUSTOM_ID" http://localhost:8001/consumers/
Without a Database
Your declarative configuration file will need to have one or more Consumers. You can create them
on the consumers:
yaml section:
consumers:
- username: user123
custom_id: SOME_CUSTOM_ID
In both cases, the parameters are as described below:
parameter | description |
---|---|
username semi-optional |
The username of the consumer. Either this field or custom_id must be specified. |
custom_id semi-optional |
A custom identifier used to map the consumer to another database. Either this field or username must be specified. |
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
With a database
You can provision new credentials by making the following HTTP request:
$ curl -X POST http://localhost: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"
}
Without a database
You can add credentials on your declarative config file on the keyauth_credentials
yaml entry:
keyauth_credentials:
- consumer: {consumer}
In both cases the fields/parameters work as follows:
field/parameter | description |
---|---|
{consumer} |
The id or username property of the Consumer entity to associate the credentials to. |
key optional |
You can optionally set your own unique key to authenticate the client. If missing, the plugin will generate one. |
Using the Key
Simply make a request with the key as a querystring parameter:
$ curl http://localhost:8000/{proxy path}?apikey=<some_key>
Or in a header:
$ curl http://localhost: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://localhost:8001/consumers/{consumer}/key-auth/{id}
HTTP/1.1 204 No Content
consumer
: Theid
orusername
property of the Consumer entity to associate the credentials to.id
: Theid
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 IAMX-Consumer-Custom-ID
, thecustom_id
of the Consumer (if set)X-Consumer-Username
, theusername
of the Consumer (if set)X-Credential-Username
, theusername
of the Credential (only if the consumer is not the ‘anonymous' consumer)X-Anonymous-Consumer
, will be set totrue
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 IAM Admin API and retrieve more information about the Consumer.
Paginate through keys
You can paginate through the API keys for all Consumers using the following request:
$ curl -X GET http://localhost:8001/key-auths
{
"data":[
{
"id":"17ab4e95-9598-424f-a99a-ffa9f413a821",
"created_at":1507941267000,
"key":"Qslaip2ruiwcusuSUdhXPv4SORZrfj4L",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
},
{
"id":"6cb76501-c970-4e12-97c6-3afbbba3b454",
"created_at":1507936652000,
"key":"nCztu5Jrz18YAWmkwOGJkQe9T8lB99l4",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
},
{
"id":"b1d87b08-7eb6-4320-8069-efd85a4a8d89",
"created_at":1507941307000,
"key":"26WUW1VEsmwT1ORBFsJmLHZLDNAxh09l",
"consumer": { "id": "3c2c8fc1-7245-4fbb-b48b-e5947e1ce941" }
}
]
"next":null,
}
You can filter the list by consumer by using this other path:
$ curl -X GET http://localhost:8001/consumers/{username or id}/key-auth
{
"data": [
{
"id":"6cb76501-c970-4e12-97c6-3afbbba3b454",
"created_at":1507936652000,
"key":"nCztu5Jrz18YAWmkwOGJkQe9T8lB99l4",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
}
]
"next":null,
}
username or id
: The username or id of the consumer whose credentials need to be listed
Retrieve the Consumer associated with a key
It is possible to retrieve a Consumer associated with an API Key using the following request:
curl -X GET http://localhost:8001/key-auths/{key or id}/consumer
{
"created_at":1507936639000,
"username":"foo",
"id":"c0d92ba9-8306-482a-b60d-0cfdd2f0e880"
}
key or id
: Theid
orkey
property of the API key for which to get the associated Consumer.