Here is the context:
The problem:
{ "message": "User is not authorized to access this resource" }
In addition, I have disabled cache for the authorizer.
What might have caused this issue?
For the REQUEST authorizer, type the valid request parameters corresponding to the specified identity sources and then choose Test. In addition to using the API Gateway console, you can use AWS CLI or an AWS SDK for API Gateway to test invoking an authorizer. To do so using the AWS CLI, see test-invoke-authorizer.
The returned values are all stringified. Notice that you cannot set a JSON object or array as a valid value of any key in the context map. You can use the context map to return cached credentials from the authorizer to the backend, using an integration request mapping template.
I am not authorized to perform an action in API Gateway If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.
This could be fixed in two ways that are described in buggy's answer: https://forum.serverless.com/t/rest-api-with-custom-authorizer-how-are-you-dealing-with-authorization-and-policy-cache/3310
Short version:
I've tried each solution and they both solved the issue with "User is not authorized to access this resource" for me.
This error will occur if you use event.methodArn
as a resource for generated policy and share an authorizer between different functions, because of how policy caching works. For provided token it caches a policy across an entire API, it will be the same cache entry for all methods and resources within the same API and stage (if they share the same authorizer).
For example, when making a request to GET /users
, ARN will look something like this:
arn:aws:execute-api:us-1:abc:123/prod/GET/users
Next call to any endpoint with the same authentication token will use a cached policy, which was created on the first call to GET /users
. The problem with that cached policy is that it's resource only allows a single particular resource arn: ... /prod/GET/users
, any other resource will be rejected.
Depending on how much do you want to limit policy permissions, you can either mention every possible resource when creating a policy
{ "principalId": "user", "policyDocument": { "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow", "Resource": [ "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/users", "arn:aws:execute-api:us-1:abc:123/prod/POST/v1/users", "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/orders" ] } ], "Version": "2012-10-17" } }
or use wildcards
"Resource": "arn:aws:execute-api:us-1:abc:123/prod/*/v?/*"
or even
"Resource": "*"
You can use policy variables for some advanced templates.
It is also possible to use a blacklist approach by allowing everything using wildcards and then denying specific resources in another policy statement.
Sources:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With