How should the developer resolve this issue?
Modify the client GET request to include a valid API key in the Authorization header.
Modify the client GET request to include a valid token in the Authorization header.
Update the resource policy for the API Gateway API to allow the execute-api:Invoke action.
Modify the client to send an OPTIONS preflight request before the GET request.
Explanations:
The Authorization header is intended for authentication, not for passing API keys. API keys are sent in a different header (x-api-key). Including an API key in the Authorization header will not authenticate the request against the Cognito authorizer and will result in a 403 error.
This option is correct because the Authorization header must contain a valid JWT token issued by Amazon Cognito for the user. If this token is missing or invalid, the API Gateway will respond with a 403 status code for the GET requests.
The execute-apiaction is related to permissions for invoking the API. A 403 error in this context is likely due to authentication failure, not a lack of permissions. Resource policies are not the issue here, as the problem is with the user’s authentication via Cognito.
An OPTIONS preflight request is typically used in CORS scenarios to check if the actual request is safe to send. While it may be part of a CORS setup, it does not resolve the issue of authentication failures with Cognito, leading to a 403 error. This is unrelated to the underlying problem of the Authorization header content.
As far as I can tell, the answer is:
Modify the client GET request to include a valid token in the Authorization header.
As I recall, the answer is:
Modify the client GET request to include a valid token in the Authorization header.