How to log in to AWS CLI with IAM Identity Center

Logging in to AWS CLI with IAM Identity Center keeps shell access tied to short-lived credentials instead of long-lived access keys. That matters on admin workstations, support shells, and deployment terminals where the next signed command might otherwise run against the wrong AWS account or permission set.

An IAM Identity Center profile in AWS CLI normally points to a reusable [sso-session …] block in ~/.aws/config. Running aws sso login authenticates that session, stores the access token under ~/.aws/sso/cache, and lets later commands exchange that token for temporary AWS credentials when the selected profile needs them.

The profile must already contain the correct start URL or issuer URL, the directory region, and the account or role mapping that should receive credentials. Current AWS CLI releases use the browser-based authorization code flow by default, while --use-device-code remains the fallback for remote shells or another device; only one active login can exist per shared sso_session, so profiles that reuse the same session name also reuse the same sign-in state.

Steps to log in to AWS CLI with IAM Identity Center:

  1. Create the IAM Identity Center profile first when the target login profile does not already exist.
    $ aws configure sso --profile my-dev-profile
    SSO session name (Recommended): my-sso
    SSO start URL [None]: https://my-sso-portal.awsapps.com/start
    SSO region [None]: us-east-1
    SSO registration scopes [None]: sso:account:access
    
    There are 2 AWS accounts available to you.
    Using the account ID 111122223333
    The only role available to you is: DeveloperAccess
    
    Default client Region [None]: us-west-2
    CLI default output format (json if not specified) [None]: json
    Profile name [my-dev-profile]: my-dev-profile

    Current AWS documentation also allows the IAM Identity Center issuer URL in place of the start URL prompt, but the resulting profile still needs the same sso_region and account or role selection.

  2. Inspect the shared config file and confirm the profile points to the intended IAM Identity Center session before starting the browser flow.
    $ sed -n '/^\[profile my-dev-profile\]/,/^$/p;/^\[sso-session my-sso\]/,/^$/p' ~/.aws/config
    [profile my-dev-profile]
    sso_session = my-sso
    sso_account_id = 111122223333
    sso_role_name = DeveloperAccess
    region = us-west-2
    output = json
    
    [sso-session my-sso]
    sso_region = us-east-1
    sso_start_url = https://my-sso-portal.awsapps.com/start
    sso_registration_scopes = sso:account:access

    Current AWS guidance keeps sso_start_url and sso_region inside the shared [sso-session …] block so one session can be reused across multiple named profiles with automated token refresh.

  3. Start the login flow for the named profile that should receive temporary credentials.
    $ aws sso login --profile my-dev-profile
    Attempting to automatically open the SSO authorization page in your default browser.
    Successfully logged into Start URL: https://my-sso-portal.awsapps.com/start

    The command also accepts --sso-session my-sso, but the profile-based form keeps the account, role, region, and output defaults aligned with the login flow.

    Only one login session can be active for a given sso_session, so signing in again with another profile that reuses the same session name refreshes the shared authentication state rather than creating a second independent login.

  4. Use the device authorization flow when the login must be approved from another machine or when the shell cannot open a browser locally.
    $ aws sso login --profile my-dev-profile --use-device-code --no-browser
    Open the following URL in another browser:
    https://device.sso.us-east-1.amazonaws.com/
    Then enter the code:
    QCFK-N451

    Current AWS CLI releases use the browser-based authorization code flow by default, so --use-device-code is the explicit fallback for jump hosts, remote SSH sessions, or terminal-only environments.

  5. Verify that the refreshed session resolves to the intended AWS account and permission set before running other commands.
    $ aws sts get-caller-identity --profile my-dev-profile
    {
        "UserId": "AROAEXAMPLEID:my-dev-profile",
        "Account": "111122223333",
        "Arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_DeveloperAccess_1234567890abcdef/my-dev-profile"
    }

    The Account and Arn fields confirm which AWS account and IAM Identity Center permission set the CLI actually resolved from the cached session.

  6. Clear the cached IAM Identity Center tokens and sign in again when the CLI keeps returning the wrong account, stale permissions, or expired-session errors.
    $ aws sso logout
    Successfully signed out of all SSO profiles.
    
    $ aws sso login --profile my-dev-profile
    Attempting to automatically open the SSO authorization page in your default browser.
    Successfully logged into Start URL: https://my-sso-portal.awsapps.com/start

    aws sso logout removes the cached authentication tokens from ~/.aws/sso/cache, which forces the next login to establish a fresh session.