AWS Amplify - Cognito login sends ACCESSKEY and SECRETKEY in the response, is this expected?

Question

When using Amplify Auth for login, I use Auth.signIn to login user with Cognito IAM based authentication documented at https://docs.amplify.aws/lib/auth/emailpassword/q/platform/js

import { Auth } from 'aws-amplify';

async function signIn() {
try {
    const user = await Auth.signIn(username, password);
} catch (error) {
    console.log('error signing in', error);
}

}

The functionality works great. Looking at the Network activity, I see Cognito-identity AWS call receives a response that has AccessKeyId and SecretKey.

{
  "AccessKeyId": "ASIAXXXX",
  "Expiration": 1612131446,
  "SecretKey": "N95AXXXXX",
  "SessionToken": "IQoJb3JXXXXX"
}

Though this key pair did not match the IAM user access and secret key I created, my questions are

1. Is accessKey and secretKey expected to be present in the response?
2. Though overall communication is SSL enabled, can these keys be misused by the user?
3. What advantage UI code has with these keys?

Appreciate your help.

My Stack:

1. Angular CLI: 10.0.8
2. Node: 10.13.0
3. OS: darwin x64
4. Angular: 10.0.14

Answer 1

Yes, this is expected behaviour.

When you login with Cognito, it provides your user with credentials that are scoped to the privileges of the Authenticated role you and/or group they are assigned to.

You then use those credentials for any API calls for that user, so that they are able to access only the resources and functionality their role is permitted to access.

For example, you can assign a user to a group which allows them access to an S3 bucket for their Cognito user. To do this you would add a policy to the authenticated user role that looks something like:

{
     “Sid”: “tensult56a5c0ff4916A”,
     “Effect”: “Allow”,
     “Action”: [
     “s3:PutObject”,
     “s3:GetObject”,
     “s3:DeleteObject”
     ],
     “Resource”: [
     “arn:aws:s3:::your-s3-bucket-name/${cognito-identity.amazonaws.com:sub}/*”
     ]
}

The policy above will allow the user to access a “sub-folder” in S3 that is named the same as their Cognito username.

Now, when the user logs in, Cognito will generate scope limited credentials that permit the user access to the resources defined in the role, and return them in the response. With the policy above, the credentials will give the user access to only the S3 bucket path that matches their Cognito username. In your app, you’ll then use those credentials anytime the user (or your app) needs to interact with AWS resources, like your S3 bucket; they’ll only be permitted to access the path that matches their Cognito username, and not another users path. If the user were a bad actor and trying to use those credentials to access a resource that is out of scope of their permissions, say they were trying to access another users S3 bucket path, they’ll get a response that lets them know they don’t have access to it (403).

The benefit is security. You have scope limited credentials which provide the user with access to only the resources you want them to have access to, and not say another users path/bucket by manipulating the API call.