Serverless my custom authorizer is not working - amazon-web-services

Question

I have the following serverless.yaml:
getSth:
handler: src/handlers/getSth.getSth
events:
- http:
path: getSth
method: get
cors: true
private: true
authorizer: authorizerFunc
authorizerFunc:
handler: src/handlers/authorizer.authorizer
getSth handler:
module.exports.getSth = async (event, context) => {
const response = {
statusCode: 200,
body: JSON.stringify({message: "nice you can call this});
}
return response;
}
authorizerFunc:
module.exports.authorizer = async (event, context) => {
console.log('i will fail your authorization');
let response = {
isAuthorized: false,
context: {
stringKey: "value",
numberKey: 1,
booleanKey: true,
arrayKey: ["value1", "value2"],
mapKey: { value1: "value2" },
},
};
return response;
}
That results in getting respons 200 in spite of the fact authorizer should not allow to execute that getSth function. Also console log 'I will fail your authorization' is not logged.
What am I doing wrong ?

Answer 1

I have tried to analyse your code and find several points where you can start digging.
Private functions
The key private: true actually makes API Gateway require an API key. I did now not try myself but perhaps private: true and an authorizer do not go together.
Strange still that you are able to call the function then. How do you call the function? From the CLI or through API Gateway and an API testing tool such as Postman or Insomnia?
Authorizer Configuration
Your authorizer configuration is definitely correct. We do have the very same setup in our code.
Authorizer Events
An authorizer function gets an APIGatewayTokenAuthorizerEvent in and should reply with a APIGatewayAuthorizerResult. The latter looks closely like an IAM statement and we do not use the field isAuthorized: false as per your example. I do not understand where this field is coming from. Our result to allow a request looks more or less like the following:
{
"principalId": "<our auth0 user-id>",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Allow",
"Resource": "*"
}]
}
}
Note how the field principalId refers to the username we get from our identity provider (Auth0). And in reality looks something like this: auth0|6f84a3z162c72d0d0d000a00.
Further, we can allow or deny the function call via the Effect field which can hold the values Allow or Deny.
Finally, you can specify which resource the caller is permitted to call. For simplicity of this answer I put * there. Of course in the real world you can pull the ARN of the called function from the event and context and pass that into the policy document.
Opinion
We also had a hard way of figuring this out via documentation from AWS. Of course for AWS the preferred integration would be via AWS Cognito (which I also do prefer due to the more streamlined integration. We benefited quite a bit form the use of TypeScript here which we use to enforce types in and out of our Serverless functions. This way it was rather easy to figure out how the response needs to look like.
Background
We use the custom authorizer integration to allow a user base already existing in Auth0 consume our Serverless based APIs via application clients or single page applications.