I have a page in my UI where I call an api gateway to update (PUT) an entity, and then on success I forward to a view page where I call an api gateway to retrieve (GET) the entity. I notice that I get random 403 failures.
If I switch off the authorizer there are no issues.
Just wondering if there is some sort of default throttle on my api that is getting hit… its really weird. My authorizer just verifys a jwt token each time -really weird
I’m seeing the same behavior. Almost every other call fails with a 403. Have you figured anything out since you posted this?
its because of cached authorizer results. With custom authorizer, the way the call works is: if the returned Lambda-generated policy is invalid or the permissions are denied, the API call does not succeed. The way the Caching works is: For a valid policy(whether allow or deny), API Gateway caches the returned policy, associated with the incoming token or identity source request parameters. It then uses the cached policy for the current and subsequent requests, over a pre-configured time-to-live (TTL) period.
The default TTL value is 300 seconds. Currently, the maximum TTL value is 3600 seconds and cannot be increased.
Your authorizer probably caches for a particular arn access for the 300 seconds. Either use wildcards for arn inside the authorizer or use TTL of 0
A common problem with custom authorizers is only returning a policy valid for the current request. You really should be returning a policy that includes everything the user can do. If you only want to return a policy for the current request then set the timeout to 0 as @walshe suggested. The downside of turning off caching is that you’ll need to execute two Lambda for every API call and this will probably impact your performance.