We are currently evaluating which authorization type to use for our production AppSync APIs.

As per AWS docs(https://docs.aws.amazon.com/appsync/latest/devguide/security.html, https://aws.amazon.com/blogs/mobile/using-multiple-authorization-types-with-aws-appsync-graphql-apis/ ), AppSync supports multiple authorization types - like API Key based (passing a static API Key), IAM role based.

My questions are around the differences between API Key based approach & IAM based one:

1)why is using a static api-key considered bad for production use cases if all calls to AppSync are HTTPS based(which has good encryption)?

2)Why can't we use a short lived token of our own along with API key & validate that token in a resolver? This would bring in some dynamism as the token is shortlived , so even if somebody hacks and gets this token ; by them time a replay happens the token is already expired?

3)The previous manual token approach seems similar to using an IAM role for Authorization. How safer would it be to use Amazon Cognito's IAM Auth. roles for this be than a manual token approach? Does the SIGV4 standard used by AWS help in anyway here?


You must log in to answer this question.

Browse other questions tagged .