Skip to content

JWT Authorizer not firing in API Gateway

0

I've configured a JTW authorizer type for one of the routes in my HTTP API Gatway. I've saved, and the stage is set to autodeploy. When I refresh the Authorization tab in API Gateway I see that the authorizer is set for the route in question. But when I use Postman to send a GET to that endpoint it is accepted (and the request is forwarded to the integration by the api gateway).

It is like the authorization is not updated for that route; since my postman is not configured to send the JWT.

Is there a way I can debug this?

~~

Adding more information to this problem:

I've configured the JWT authorizer for a GET /route request. I have my previous authorizer lambda function (previous authorizer) configured for GET /route/{id}. The previous authorizer looks for a string in the 'api-key' property of the HTTP headers. The previous authorizer may be an important clue, see below.

When I use Postman to send a GET /route request, I am NOT sending any JWT token in the headers; I'm instead sending my request with the 'api-key' HTTP header set as if I was using my older authorizer function. When I do that, I can use CloudWatch to see that my old authorizer is being triggered, even though the new (JWT) authorizer is assigned to the GET /route endpoint.

In the API Gateway CloudWatch logs, I see my old authorizer function log the request with the parameters below:

'routeKey': 'GET /route/{id}', 'rawPath': '/route/', 'http': {'method': 'GET', 'path': '/route/', 'protocol': 'HTTP/1.1'

So my old function is firing, despite the new JWT authorizer being configured for GET /route (which I've triple checked)

Not sure how routeKey works, but for this request (which doesn't have an {id} set) I'm surprised the routeKey has the {id} parameter.

1 Answer
0

It sounds like you're experiencing an issue where your JWT authorizer is not being applied as expected to your HTTP API Gateway route. There are a few things you can check to debug this issue:

  1. Verify the authorizer configuration: Make sure the JWT authorizer is correctly configured with the proper issuer, audience, and identity source. Double-check that the audience in your configuration matches the intended audience for your JWT tokens.

  2. Check the deployment: Although you mentioned that the stage is set to autodeploy, it's worth confirming that the changes have been properly deployed. Try manually deploying the API to ensure the latest configuration is active.

  3. Examine the request: When sending requests through Postman, ensure you're targeting the correct API endpoint and stage. Sometimes, the issue can be that you're hitting a different version of the API or a route that doesn't have the authorizer applied.

  4. Validate the JWT token: Even though your Postman is not configured to send the JWT, try sending a request with a valid JWT token in the Authorization header. This can help determine if the issue is with the authorizer configuration or the lack of a token.

  5. Check API Gateway logs: Enable logging for your API and check the CloudWatch logs. This can provide insights into whether the authorizer is being triggered and if there are any errors during the authorization process.

  6. Use the API Gateway console: The API Gateway console has built-in tools for testing your routes. Try using these to test your endpoint with and without a valid JWT to see if the behavior differs from Postman.

  7. Decode and verify JWT: Use a tool like jwt.io to decode your JWT and verify that it matches the issuer, audience, and scopes that your API requires. This can help identify any mismatches in the token claims.

  8. Check for caching issues: API Gateway caches the public key used for JWT validation for up to two hours. If you've recently updated your JWT configuration, you might need to wait for the cache to clear or force a redeployment.

If none of these steps resolve the issue, you may want to review the full configuration of your API, including any other authorizers or security measures that might be interfering with the JWT authorizer. Additionally, ensure that your JWT authorizer is correctly attached to the specific route you're testing, as it's possible to have different authorization settings for different routes within the same API.

Remember, for API Gateway to authorize a request, the JWT's aud or client_id claim must match one of the audience entries configured for the authorizer. If both are present, API Gateway evaluates the aud claim.

If you continue to experience issues, you may need to contact AWS support for further assistance in troubleshooting your specific API Gateway configuration.

Sources
Troubleshooting issues with HTTP API JWT authorizers - Amazon API Gateway
Control access to HTTP APIs with JWT authorizers in API Gateway - Amazon API Gateway
Create and troubleshoot Cognito and API Gateway integrations | AWS re:Post
Configure an API Gateway Lambda authorizer - Amazon API Gateway

answered 2 years ago

EXPERT

reviewed 2 years ago

  • The thing is, it should be more difficult to get an unauthorized request through rather than vice versa. It's like this route is using my old authorizer, not the newly configured one. It accepts traffic without the Authorization header.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.