8
votes

In AWS API Gateway,
- We can set up a resource to reqiure API Key for access.
- We can also set up another resource to require Authorization (e.g. JWT token, handled via a lambda function or AWS Cognito).

The question: can we configure a resource to be accessible in either of the above two situations? Currently, if we enable "API Key Required" and "Authorization" simultaneously, the request needs both the API Key and the Authorization. We were hoping for it to pass with only one of the two.

Hack/workaround: Create two copies of the same resource, and authorize each separately, one with API Key and the other one with an authorizer.

2
Hello, I have the exact same case and I am struggling with it for a few hours so far. Could you please tell me how you solved it? Many-many thanks in advance. I see your hack/workaround but maybe you figured out how it can be achieved using one resource?Vladyslav Turak
I implemented a lambda function and used that as the authorizer. That gave me enough flexibility to have all kinds of JWT authorization as well apikey authentication.Amir

2 Answers

1
votes

Let authorizer generate/map the API key for you

You have a Lambda authorizer return the API key as part of the authorization response. For more information on the authorization response, see Output from an Amazon API Gateway Lambda authorizer.

Pros:

  • Single end-point

  • API key is more for usage plan than authorization. Keep it that way.

Cons:

  • Authorizer will run on each request. Which cost money
1
votes

Authentication, Identification, Authorization are intertwined concepts. As I got more educated on Auth, here is my answer:

  • API Keys are used for project/application identification and authorization
  • JWT are used for user authentication and authorization.
  • API Key is on project/application scope and JWT is on user scope. In other words, API Key only identifies the application, not the user of the application.

Accordingly, it makes sense not to authorize the same endpoint with both JWT and API Key as it would reduce the governance granularity for users and applications. But, if you have a usecase that requires that type of authorization, the suggested workaround could work.