Reputation: 1571
I'm trying to setup Google API Gateway to use an API key that callers send in the header.
My api config yaml looks like this:
...
securityDefinitions:
api_key_header:
type: apiKey
name: key
in: header
api_key_query:
type: apiKey
name: key
in: query
paths:
/foo-header:
get:
summary: Test foo endpoint
operationId: testGet-header
x-google-backend:
address: "<backend address>"
protocol: h2
path_translation: APPEND_PATH_TO_ADDRESS
security:
- api_key_header: []
responses:
204:
description: A successful response
/foo-query:
get:
summary: Test foo endpoint
operationId: testGet-header
x-google-backend:
address: "<backend address>"
protocol: h2
path_translation: APPEND_PATH_TO_ADDRESS
security:
- api_key_query: []
responses:
204:
description: A successful response
I expect both calls, /foo-header
and /foo-query
to fail with 401 status if a valid API key is not provided via header or query parameter.
But in a fact only /foo-query
behaves as expected.
Requests to /foo-header
pass to the backend even when the API key is not provided in request header.
Do I have issue with the config, or is it the Google API Gateway that doesn't work properly when API key is provided in request header?
Upvotes: 8
Views: 6837
Reputation: 1
Still the issue happens. As workaround, you can only define api_key and all endpoints will work with both query and header api key.
securityDefinitions:
api_key:
type: "apiKey"
name: "key"
in: "query"
Upvotes: 0
Reputation: 476
When in
is header
, the name
should be x-api-key
.
https://cloud.google.com/endpoints/docs/openapi/openapi-limitations#api_key_definition_limitations
Upvotes: 10
Reputation: 2642
It seems that the Google API Gateway should work fine when the API key is provided in request header since the Google API Gateway documentation states:
A developer generates an API key in a project in the Cloud Console and embeds that key in every call to your API as a query parameter or in a request header.
However, I was able to reproduce the behavior you reported, thus I don't think that there is something wrong in your configuration.
For that I'd been following the GCP quickstart for the Google API Gateway, modifying it slightly so that my OpenAPI spec would also have 2 paths: one is looking for a key in query parameters, while another in the request header.
paths:
/foo-header:
get:
summary: Test security
operationId: headerkey
x-google-backend:
address: [MY_CLOUD_FUNCTION_1]
security:
- api_key_header: []
responses:
'200':
description: A successful response
schema:
type: string
/foo-query:
get:
summary: Test security
operationId: querykey
x-google-backend:
address: [MY_CLOUD_FUNCTION_2]
security:
- api_key_query: []
responses:
'200':
description: A successful response
schema:
type: string
securityDefinitions:
# This section configures basic authentication with an API key.
api_key_header:
type: "apiKey"
name: "key"
in: "header"
api_key_query:
type: "apiKey"
name: "key"
in: "query"
Just like you, I could see the requests to the /foo-header
pass to the backend even when there was no API key provided.
I would suggest you to report this issue on the Public Issue Tracker, so that it would be reviewed by an appropriate GCP engineering team.
Upvotes: 2