AWS CLI SSO: Fix Expired Tokens and Wrong Account Errors

Scope: This guide covers AWS CLI version 2 with modern IAM Identity Center configuration using named profiles and sso-session sections. The account names and command responses below are examples. Replace every placeholder with values supplied by your organisation. Don’t paste real account IDs, ARNs, tokens, or local paths into public logs or support requests.

If an AWS CLI command says your SSO token has expired, the usual first step is to sign in again with the profile you meant to use:

aws sso login --profile dev

If the command runs but targets the wrong account, stop before making changes. Ask the CLI who it is acting as:

aws sts get-caller-identity --profile dev

These are different problems. A fresh login can renew an expired Identity Center sign-in, but it won’t change a profile’s account or grant missing permissions. Verify the active identity before retrying a service command.

Check identity before changing anything

Start with three read-only checks: confirm that the CLI is version 2, see which configuration sources a named profile resolves, and ask AWS for the effective caller. sts get-caller-identity returns the account and identity associated with the request. Its output is useful precisely because it reflects the credentials the CLI actually used, not just the profile name you intended to use. AWS documents the command and its response fields.

aws --version
aws configure list --profile dev
aws sts get-caller-identity --profile dev

The commands above are an example diagnostic sequence, not captured results. Your output depends on your machine and account. In aws configure list, the source and location columns can help identify whether a value came from a profile file, environment, or another source. Sensitive values may be masked; don’t try to uncover them by printing credential files or environment values.

The caller-identity response normally includes an account identifier and an ARN. Compare those identifiers with the account and role you expected. An ARN identifies the caller’s AWS identity, but the exact form can vary with the identity and role session.

Use the same profile for the check and the later command. If you omit --profile, the CLI may use its default profile or other available credential sources. A profile named dev is only a local label; the returned account and ARN tell you where the request actually went.

Understand the session, profile, account, and role

Four related terms are easy to mix up:

Sign-in, profile settings and the effective caller are connected but distinct. Verify the identity before acting on an AWS resource.

• Identity Center session: The sign-in session established through your organisation’s IAM Identity Center access portal.
• Profile: A named set of AWS CLI settings you select, such as dev or staging.
• Account: The AWS account selected for the profile’s role access.
• Role: The set of permissions made available when you access that account through Identity Center.

A profile can refer to an Identity Center session and specify an account ID and role name. Signing in establishes or refreshes access; it doesn’t make every profile point to the same account, nor does it make every action permitted. The modern setup separates the reusable SSO session settings from profile-specific account and role settings. See AWS’s IAM Identity Center CLI configuration guide for the configuration model.

Here’s a fictional example. The account IDs are placeholders; they are not real account information.

[sso-session company]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile dev]
sso_session = company
sso_account_id = 111122223333
sso_role_name = DeveloperReadOnly
region = us-east-1
output = json

[profile staging]
sso_session = company
sso_account_id = 444455556666
sso_role_name = StagingReadOnly
region = us-west-2
output = json

This is an illustrative configuration excerpt for the AWS CLI config file, typically ~/.aws/config on macOS and Linux or %UserProfile%\.aws\config on Windows. It is not a complete description of every organisation’s setup: your Identity Center administrator may use different URLs, regions, accounts, roles, or access arrangements. Don’t invent a start URL or role name; use the values provided for your organisation.

Both profiles refer to the company SSO session, but they select different accounts and roles. That lets a developer use one sign-in session for more than one assigned profile. It doesn’t imply that the user has access to both accounts: the organisation must grant the relevant account and role assignment.

Configure a profile and sign in

If you need to create or update a profile, use the interactive configuration command:

aws configure sso

Answer the prompts with your organisation’s Identity Center start URL and region, then select an account and role you’re authorised to use. The CLI can open a browser for sign-in or provide a device authorisation flow, depending on the situation. Follow the prompts and your organisation’s sign-in process. Avoid copying browser codes, tokens, or other authentication details into notes, terminals shared with others, or support tickets.

After configuring the profile, sign in explicitly with its name:

aws sso login --profile dev

Then confirm the result before using a service command:

aws sts get-caller-identity --profile dev

A successful sign-in means the CLI completed the authentication flow. The identity check confirms which caller a subsequent request using that profile resolves to. It doesn’t prove that a particular S3, IAM, or other service action is allowed.

For a command-line workflow, keep the profile selection consistent. For example, if you use --profile staging to check identity, use --profile staging on the later read-only service command too. Switching profile names changes which profile settings the CLI uses.

Expired token versus expired Identity Center login

“Expired token” can describe more than one point in the credential chain. The CLI may have cached short-lived role credentials that need renewal, or the underlying Identity Center login may have expired. AWS notes that role credentials can renew while the Identity Center login remains valid; if the Identity Center login expires, you need to sign in again. Renewal isn’t unlimited unattended access: a user may still need to complete an interactive sign-in when the login session expires.

A new login can resolve expiry. It does not correct a wrong account setting or grant a missing permission.

Symptom	What it may mean	Safe next step
A command reports expired or invalid SSO credentials	The cached role credentials or Identity Center login may no longer be usable.	Run aws sso login --profile name, then verify the caller identity.
A command works for a while, then asks for sign-in again	The Identity Center login may have expired, even if role credentials had renewed earlier.	Complete a fresh sign-in when prompted. Ask your administrator about your organisation’s session policy if the timing is unexpected.
Login succeeds, but a service returns AccessDenied	Authentication may be valid, while the role lacks the requested permission or resource access.	Check the caller identity, action, resource, and role assignment; don’t treat this response as proof that SSO has expired.
The account in the identity response is unexpected	The selected profile, its account setting, or the credentials in use may differ from your intention.	Pause. Inspect profile resolution and credential sources before retrying.

For an expiry-related error, try the least disruptive action first: log in again with the intended profile, then repeat the read-only identity check. Don’t start by running aws sso logout. That command affects cached SSO sessions beyond a single illustrative profile, so it can interrupt other profile use as well. Consider broader logout only when you understand the effect and have a reason to clear those sessions.

Diagnose a wrong account and credential precedence

A profile name doesn’t guarantee that every credential source on your machine belongs to that profile. One frequent source of confusion is an AWS_PROFILE environment variable used alongside environment variables containing access-key credentials.

When AWS_PROFILE is used alongside access-key variables, environment credentials can win. Check the invocation and effective caller; explicit --profile has its own resolution behavior.

When AWS_PROFILE selects a profile, environment access-key credentials can take precedence over profile-file credentials. In other words, selecting a profile through AWS_PROFILE does not necessarily mean the CLI will use that profile’s credentials if access-key variables are also set. Precedence depends on how the CLI is invoked and which settings are present, so avoid assuming that one rule covers every explicit --profile invocation. AWS documents the distinctions in its configuration precedence reference and environment variable reference.

First, check which credential-related variable names are set. These commands print variable names only, not values.

# macOS or Linux: print names of AWS-related variables, not their values
env | cut -d= -f1 | grep '^AWS_'

This is a limited inspection, not a complete account diagnosis. An environment variable’s presence doesn’t by itself prove which identity a request used. aws configure list and sts get-caller-identity provide safer evidence about configuration and effective identity without dumping secret values.

If you suspect inherited environment variables are interfering, try a clean subshell rather than changing credential files. The following macOS/Linux example starts a subshell, clears selected credential variables only inside it, selects the intended profile, and checks identity. Exiting the subshell returns you to the original shell environment.

env -u AWS_ACCESS_KEY_ID \
  -u AWS_SECRET_ACCESS_KEY \
  -u AWS_SESSION_TOKEN \
  -u AWS_SECURITY_TOKEN \
  AWS_PROFILE=dev \
  sh

At the new shell prompt, run:

aws configure list
aws sts get-caller-identity

When you’re done, type exit. This approach is temporary. It doesn’t delete credential files, clear SSO caches, or permanently change your shell configuration. If your organisation uses additional credential-provider variables, ask an administrator which ones are appropriate to remove for a diagnostic session.

In Windows PowerShell, you can inspect AWS variable names without printing their values, then create a separate process with selected access-key variables removed:

Get-ChildItem Env: |
  Where-Object { $_.Name -like 'AWS_*' } |
  Select-Object -ExpandProperty Name

$cleanCommand = 'Remove-Item Env:AWS_ACCESS_KEY_ID, Env:AWS_SECRET_ACCESS_KEY, Env:AWS_SESSION_TOKEN, Env:AWS_SECURITY_TOKEN -ErrorAction SilentlyContinue; $env:AWS_PROFILE = "dev"; aws configure list; aws sts get-caller-identity'
powershell.exe -NoProfile -Command $cleanCommand

The child PowerShell process receives the diagnostic commands; the parent PowerShell session is not changed by those removals or by setting AWS_PROFILE inside the child. If your shell policy or environment differs, adjust the method with your workstation support team rather than deleting credential files.

Environment credentials and profile settings are only part of the picture. Check the configured account and role in the chosen profile, the profile name used by the command, and the identity response. Region is a separate setting: a wrong region can cause a command to look in the wrong place, but changing region won’t correct an unexpected account or renew an expired login.

A small wrong-account example

Imagine that you have two approved profiles: dev for a development account and staging for a staging account. You intend to list a development bucket, but the command returns an unexpected account in the identity check. Before trying another S3 command, make the mismatch visible.

Run the identity check with the profile written directly on the command:

aws sts get-caller-identity --profile dev

For this fictional exercise, the account field should identify the development account configured in your profile. The following response is an example of the shape to inspect, not output collected from an account:

{
  "UserId": "EXAMPLESESSION:reader",
  "Account": "111122223333",
  "Arn": "arn:aws:sts::111122223333:assumed-role/ExampleReadOnly/reader"
}

Now compare that result with aws sts get-caller-identity without the profile flag. If they identify different accounts, you have narrowed the problem to selection or credential resolution. The S3 bucket has not changed, and logging in repeatedly is unlikely to help until you understand which identity each command uses.

Next, check aws configure list for the invocation that went wrong. Look at the source of the credentials and the selected profile. If environment credentials are involved, try the temporary clean shell shown earlier. If the account is still wrong when the intended profile is selected, inspect that profile’s account setting and role assignment. A familiar local profile name can point to an unfamiliar account after a configuration change.

Finally, repeat the identity check using the exact command style you will use for the real operation. Keep this check beside the command in your notes. It gives you a clear boundary: first confirm the destination account, then investigate whether the role has permission for the requested operation. There is no need to create a resource or modify a policy to complete this exercise.

When login works but a service says AccessDenied

Authentication answers, “Who is making this request?” Authorization answers, “May that identity perform this action on this resource?” A successful SSO login does not grant every service action. An AccessDenied response therefore does not, by itself, mean that the login expired.

Use a small diagnosis sequence:

1. Run aws sts get-caller-identity --profile name and compare the account and caller with your intended role.
2. Confirm the exact profile used by the denied command, and check its configured account and role.
3. Identify the specific action and resource the command tried to access. Avoid pasting sensitive resource identifiers into public reports.
4. Ask an authorised administrator to check the role assignment and the applicable permissions for that action and resource.

Permissions can depend on more than a single identity policy, including the resource being accessed and the organisation’s account controls. Don’t respond to a denial by attaching broad administrator permissions or repeatedly trying unrelated roles. Provide the administrator with the command, a redacted error, the intended account and role, and the action/resource context they need to investigate.

For IAM-related CLI examples, see the guide to IAM user commands and the guide to IAM role commands. Those guides don’t replace checking which identity is active or confirming that the requested operation is permitted.

Interactive SSO and unattended automation

IAM Identity Center sign-in is designed around a user completing an interactive authentication flow. That’s a natural fit for a developer at a workstation, where signing in again when the session expires is possible. It may not fit an unattended job that must run without a person present. A job can fail when an interactive login expires, even if it worked earlier.

For a scheduled workload or deployment system, use an organisation-approved workload identity or role-assumption design appropriate to that platform. Ask the platform or cloud administrator which identity method is supported. Don’t work around an expired interactive session by copying a user’s long-lived access keys into a script, build log, or environment configuration. For an interactive session that needs renewed access, use the configured SSO profile and sign in again as required.

Read-only verification checklist

Before retrying an AWS service command, check the basics in this order:

1. Confirm that aws --version identifies AWS CLI version 2.
2. Use aws configure list --profile name to review the selected profile and configuration sources without exposing secrets.
3. If authentication appears expired, run aws sso login --profile name.
4. Run aws sts get-caller-identity --profile name and compare the returned account and ARN with your intended identity.
5. If the account is wrong, check the profile’s account and role and consider whether environment credentials are interfering. Use a temporary clean shell for diagnosis instead of deleting credential files.
6. If the identity is right but the service denies access, treat it as an authorization issue and request a targeted permission review.
7. Check the region independently when a resource isn’t where you expect it.

Once the identity is confirmed, you can move on to a low-risk operation permitted by your role. For example, if you have the required read permissions, follow the guide to list S3 buckets and objects. Keep the same profile explicit in the command and stop if the identity check doesn’t match your intended account.

Final checks you can verify

Use these commands as a final read-only check, replacing dev with the profile you intend to use:

aws --version
aws configure list --profile dev
aws sts get-caller-identity --profile dev

If the last command identifies the intended account and caller, your next step depends on the error: sign in with aws sso login --profile dev if the login expired, or ask for a targeted authorization review if the service returned AccessDenied. Don’t proceed with a cloud change until the identity and account are the ones you expect.

If a problem remains, share only redacted diagnostic details with your support team: the CLI version, profile name if permitted, command shape, error text with sensitive identifiers removed, and whether the caller identity matched. Don’t send tokens, secret values, complete credential files, or unredacted SSO cache data.