Connect to API Gateway with IAM Auth

From @jayair on Wed Jul 19 2017 19:49:19 GMT+0000 (UTC)

Link to chapter - http://serverless-stack.com/chapters/connect-to-api-gateway-with-iam-auth.html

Copied from original issue: https://github.com/AnomalyInnovations/serverless-stack-com/issues/113

From @p31d3ng on Thu Aug 03 2017 07:25:45 GMT+0000 (UTC)

```
if (AWS.config.credentials && Date.now() < AWS.config.credentials.expireTime - 60000) {
return;
}


This block of code in `function getAwsCredentials(userToken)` will create some issues if a user login to a different account before `AWS.config.credentials` expires.

Imagine the following scenario on a certain machine:
1) User A login
2) User A creates a new note
3) User A logs out
4) User B login
5) User B sees all notes of User A. Because `AWS.config.credentials` exists and not yet expires,  the `userId` of the outgoing requests are actually from user A.

From @jayair on Thu Aug 03 2017 17:29:58 GMT+0000 (UTC)

@p31d3ng It’s not in this chapter but we clear the credentials when a user logs out.

I should also add that there is a bit of an issue with the current logout code that I’ll be putting out a fix for soon - https://github.com/AnomalyInnovations/serverless-stack-com/issues/50#issuecomment-318939817.

From @yashg5 on Fri Aug 04 2017 07:24:04 GMT+0000 (UTC)

is there any easy to trigger API calls by using AWS SDK without manually signing the request so that AWS SDK takes care of signing process. is it possible like this from mobile front end using AWS IOS SDK?

From @jayair on Sun Aug 06 2017 23:46:41 GMT+0000 (UTC)

@yashg5 We can disable IAM temporarily and test our APIs but we would need to mock where we get our user id from.

You should be able to do a similar setup from iOS as well.

From @QuantumInformation on Thu Oct 05 2017 21:55:24 GMT+0000 (UTC)

Anyone know why AWS passes over to the user all this complexity (signing etc) instead of handling it with the sdk, kinda like what firebase does? I’m sure there are good reasons.

From @jayair on Fri Oct 06 2017 18:11:32 GMT+0000 (UTC)

@QuantumInformation I think the Firebase equivalent would be if you used the Cognito User Pool on it’s own and instead of IAM as the authorizer use the User Pool as the authorizer. Unfortunately you still need to work with IAM roles and such when you need to work with S3 or other AWS resources.

One of our older versions covers this setup - https://59caadbd424ef20abdc342b4–serverless-stack.netlify.com/chapters/call-the-create-api.html.

We might add a chapter on why use IAM as an authorizer vs User Pool.

From @QuantumInformation on Fri Oct 06 2017 21:53:49 GMT+0000 (UTC)

lol I thought we used the User Pool as the authorizer

From @jayair on Fri Oct 06 2017 22:38:45 GMT+0000 (UTC)

@QuantumInformation AWS is pretty confusing but I should have been more clear, we are using IAM as an authorizer for API Gateway. But to talk to API Gateway we generate a set of temporary credentials through Cognito Federated Identities where the User Pool is the authentication provider.

From @zacacollier on Tue Oct 10 2017 13:21:24 GMT+0000 (UTC)

@jayair first of all thank you for writing this section, it is super helpful. I was surprised at how hard it was to find a straightforward, pluggable solution for signing requests on the client (most of what I came across was intended for serverside use)

just wanted to point out that the rawgit link to the sigV4Client.js is out of date, I encountered an issue while trying to sign a request, but when I went to open a PR I discovered you’d fixed it on master

From @jayair on Wed Oct 11 2017 17:13:41 GMT+0000 (UTC)

@zacacollier Thank!

For the sigV4Client.js, I’m not sure I see the issue you are talking about because that file has never been edited (if you check the history, https://github.com/AnomalyInnovations/serverless-stack-demo-client/commits/master/src/libs/sigV4Client.js). I wonder what didn’t work for you.

From @tommedema on Wed Oct 18 2017 07:18:43 GMT+0000 (UTC)

Hi all. I’m confused as to why we need to deal with IAM role creation and Policy Documents like these:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "mobileanalytics:PutEvents",
        "cognito-sync:*",
        "cognito-identity:*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_S3_UPLOADS_BUCKET_NAME/${cognito-identity.amazonaws.com:sub}*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "execute-api:Invoke"
      ],
      "Resource": [
        "arn:aws:execute-api:YOUR_API_GATEWAY_REGION:*:YOUR_API_GATEWAY_ID/*"
      ]
    }
  ]
}

Isn’t serverless.com supposed to take care of this complexity, and automatically create and assign roles when necessary?

My biggest pain in following the guide is how specific it is to AWS and how much knowledge is required on the specifics on AWS services. I had expected these to all be abstracted away into the serverless framework.

From @QuantumInformation on Wed Oct 18 2017 09:51:21 GMT+0000 (UTC)

You’ll never be able to completely abstract away AWS otherwise you will end up with more complexity. My next video will cover this policy file as it isn’t that hard once you get it.

From @jayair on Thu Oct 19 2017 17:35:48 GMT+0000 (UTC)

@tommedema It’s an interesting thought for sure. One of the unwritten aspects of the serverless approach is that you are investing more in the specific cloud provider’s services and methods.

Serverless Framework (or potentially any other framework) could abstract these out but then you’ll be relying heavily on which features of the cloud provider they expose to you. Serverless Framework has decided that they want to be a layer on top of all these providers instead of being a specific solution for AWS. This is why a lot of this has not been abstracted out.

From @dailenspencer on Mon Oct 30 2017 17:01:24 GMT+0000 (UTC)

Still receiving the following error if anyone has any thoughts :slight_smile:

TypeError: __WEBPACK_IMPORTED_MODULE_4__sigV4Client__.a.newClient(...).signRequest is not a function

From @jayair on Mon Oct 30 2017 21:01:46 GMT+0000 (UTC)

@dailenspencer Can I try your project somehow? I want to see what is going.

From @dailenspencer on Mon Oct 30 2017 21:08:37 GMT+0000 (UTC)

@jayair yes, if you click on this link you should be able to have access
https://github.com/dailenspencer/Element/invitations

From @jayair on Mon Oct 30 2017 21:12:26 GMT+0000 (UTC)

@dailenspencer Got it. How to I reproduce the error again?

From @dailenspencer on Mon Oct 30 2017 22:41:02 GMT+0000 (UTC)

@jayair Steps to reproduce

  1. Run yarn install
  2. Run yarn start and wait for app to load at localhost:3000
  3. Head to localhost:3000/signin and login with the following credentials

username: dailenspencer@gmail.com
password: Sodacan123!

From @dailenspencer on Mon Oct 30 2017 22:42:38 GMT+0000 (UTC)

I’ve just pushed an update so you may want to re-pull if you’ve already cloned the project