[Feature Request] Amplify CLI support AWS SSO

[v1pz3n]

Describe the bug

$ amplify env pull
⠦ Fetching updates to backend environment: dev from the cloud.(node:10308) UnhandledPromiseRejectionWarning: Error: connect EHOSTUNREACH 169.254.169.254:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:10308) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:10308) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
⠋ Fetching updates to backend environment: dev from the cloud.

Amplify CLI Version 4.21.1

To Reproduce

1. aws sso login --profile dev
2. amplify pull or amplify env pull

Expected behavior Update my local development environment

Desktop

• OS: Linux Mint 19.3
• Node Version. v14.3.0

[djheru]

I'm trying to understand design philosophy here. Amplify cli by default forces users to create an IAM long-lived key and secret. Which is a big no-no. What's the consideration for these defaults?

What's the alternative for security-aware organization with SSO?

amplify configure
Follow these steps to set up access to your AWS account:

Sign in to your AWS administrator account:
https://console.aws.amazon.com/
Press Enter to continue

Specify the AWS Region
? region:  us-east-1
Follow the instructions at
https://docs.amplify.aws/cli/start/install/#configure-the-amplify-cli

to complete the user creation in the AWS console
https://console.aws.amazon.com/iamv2/home#/users/create
Press Enter to continue

Enter the access key of the newly created user:
? accessKeyId:  [hidden] 

You can skip the amplify configure operation after install if you already have a profile you want to use (either regular IAM or SSO). This is a big omission IMO in the documentation. When you run amplify init in your project, you can select "AWS Profile" or "AWS Access Keys". To my mind, using long-lived access keys here is a bad practice, so using profiles is preferred.

I came across this thread trying to figure it out, this is what I ended up with:

[profile dev]
sso_start_url=https://XXXXXXXXXXXX.awsapps.com/start
sso_region=us-east-1
sso_account_id=XXXXXXXXXXXX
sso_role_name=AdministratorAccess
region=us-east-1
output=json
cli_pager=
sso_session=dev
credential_process=aws sso login --profile dev
[sso-session dev]
sso_start_url=https://XXXXXXXXXXXX.awsapps.com/start
sso_region=us-east-1
sso_registration_scopes=sso:account:access

[profile prod]
sso_start_url=https://XXXXXXXXXXXX.awsapps.com/start
sso_region=us-east-1
sso_account_id=XXXXXXXXXXXX
sso_role_name=AdministratorAccess
region=us-east-1
output=json
cli_pager=
sso_session=prod
credential_process=aws sso login --profile prod
[sso-session prod]
sso_start_url=https://XXXXXXXXXXXX.awsapps.com/start
sso_region=us-east-1
sso_registration_scopes=sso:account:access

Hope it helps!

[kaunglvlv]

I have SSO set up with Google Workspaces. The issue was with Chrome. When it tried to authenticate during the completion of amplify init, it opened a new Chrome window which had one of my other Google accounts signed in and used that to automatically authenticate which failed with the following error

Failed to get profile credentials

I manually signed out of this profile and went through amplify init again. This time it asked me to sign in to my Google account. Signed in with the correct account hooked up to SSO and it worked. Hope this helps for anyone with Google Workspaces where you may have multiple accounts on your Chrome browser.

[darrenleomiller]

The Rosetta Stone for me was finding that amplify uses the profile information stored in (for example) amplify/.config/local-aws-info.json which will look something like this:

{
  "dev": {
    "configLevel": "project",
    "useProfile": false,
    "awsConfigFilePath": "/Users/bilbo/.amplify/awscloudformation/nQKUFafyPf"
  }
}

or like this:

{
  "dev": {
    "configLevel": "project",
    "useProfile": true,
    "profileName": "bilbo-admin"
  }
}

The file in the first example needs to contain updated credentials or you will eventually get the dreaded The provided token has expired error. You can get those details with aws configure export-credentials --profile bilbo-admin among others.

It's also worth noting that the tokens from aws-sso-util (brilliant!) and aws sso login are not interchangeable and can coexist for the same named profile.

The bottom line is that this file controls everything - if you aren't updating those specific credentials or using that named profile you are barking up the wrong tree (as I did for way too long).