Convince me to use API-Gateway and not call Lambda direct

aws

#21

All my users need to be registered and I don’t allow unauthenticated user; therefore, I can’t escape the cost for using user pool.

The API Gateway custom authorizer such looks like a cleaner way to do my app authorization check. But doing a quick cost calculation, it’s still more expensive than if I can do it in my Lambda function or even use Step Function. Again, out of topic, sorry, but I’m thinking a couple of ways to do it without API Gateway:

  1. Do a Pre-Token Generation trigger in Cognito to check and add in addition claims pertaining to the user’s authorization against my custom rules (stored in dynamodb). My lambda function will then look at the claims and decide if the user can execute or not in the app logic

  2. My Lambda function will check the user’s authorization against my custom rules and decide if the user can execute or not in the app logic.

Have you considered these 2 methods back then? Nonetheless, I’m stuck at both methods. I could hardly find any sample in writing Pre-Token Generation lambda in .net/java. And in the Lambda context, it only has the user’s CognitoID, and with the CognitoID, I can’t link it to the user in my UserPool. You know of a way?

I’m thinking of passing the jwt token as an parameter into my function, but not sure how secure it is. With API Gateway, I could use HTTPS to have it encrypted on the network layer. But with lambda direct invoke, can it be spoofed easily?


#22

That pre-token call only works on User Pools, not Federation Pool. User Pools have JWT tokens, Federation Pools have opaque AWS specific tokens.

Another solution that I have not tried is to use multiple Federation Pools, one for each authorization level.

If you are using the User Pools with different groups like admin, when you get into to lambda you can look in the environment and see which execution role it picked. You don’t need to reverse map the CognitoID back to the pool. Each user type (like groups) can be assigned a custom execution role. That will allow you to identify the user type.

this may help… https://github.com/aws-amplify/amplify-js/issues/1022