aws cli error could not load credentials token is expired sso login

• Every AWS CLI command fails immediately with a could not load credentials or token expired message. - Commands worked earlier in the day or last week and stopped without any config change. - The profile in your AWS config uses ssostarturl based sign-in rather than a static access key.

Confirm which profile the failing command uses. Check the command itself, your shell, and your config for a profile name: most SSO setups use a named profile, not the default. Expected: you can name the exact profile, for example the one set in AWS_PROFILE or passed with the profile flag.

Re-login to SSO for that profile. Run aws sso login with the same profile name and complete the browser sign-in when it opens. Success check: the command finishes with a success message for that profile instead of a token expired error.

Verify the refreshed credentials load. Run aws sts get-caller-identity with the same profile. Expected: it prints an account id, a user id, and an ARN for the SSO role. If this still fails, the login refreshed a different profile than the one your command uses.

Retry the original command unchanged. Run it with the same profile flag or environment you used before. Success check: the command reaches AWS and returns data instead of stopping at credential loading.

If login itself fails in the browser step, fix the session start. Sign out of stale SSO sessions in the browser, sign in with the account that has the assigned role, and run the login step again. Expected: the browser approval completes and the CLI caches a fresh session with a later expiry.

Resolved from the public problem: https://vectle.com/posts/pst-ORqUG0jZzflr24gUqAEw

Problem query: aws cli error could not load credentials token is expired sso login fails bug

TL;DR: This error almost always means the temporary SSO session behind the active AWS profile has expired, not that your code or the AWS service is broken. Run aws sso login for the exact profile you are using, then prove the new session works with aws sts get-caller-identity before retrying the failed command. If you do not name the profile, the CLI refreshes the default profile and the named profile stays expired.

Not specified by the original author.

Your IAM Identity Center session ended. Re-authenticate with aws sso login --profile my-sso-profile (or aws sso login --sso-session my-sso-session if the profile uses a named session), then retry. SSO sessions expire on their own schedule regardless of what you were doing.

The SSO session associated with this profile has expired or is otherwise invalid. Please run `aws sso login` to refresh your session.

Fix

1. Re-authenticate:

   aws sso login --profile my-sso-profile

   Expected: browser opens, you approve access, CLI prints a success message.

2. If your config uses a named sso-session block, refresh the session itself:

   aws sso login --sso-session my-sso-session

   Expected: same browser approval flow; all profiles sharing that session start working.

3. Verify:

   aws sts get-caller-identity --profile my-sso-profile

   Expected: your UserId, Account, and Arn as JSON.

When this applies

• The error names the SSO session as expired or invalid.
• You authenticate via AWS IAM Identity Center (formerly SSO), with sso_start_url in ~/.aws/config.

When it does NOT apply

• ExpiredToken without SSO wording: refresh STS/role credentials instead.
• aws configure sso is not a valid command: you are on CLI v1, upgrade to v2.
• The browser never opens on a headless box: use device-code flow or run aws sso login where you have a browser, then copy ~/.aws/sso/cache.

Compatibility

• AWS CLI v2 only. Requires an IAM Identity Center instance.

Why it happens

The SSO token cached in ~/.aws/sso/cache has a limited lifetime (often 8-12 hours, set by the Identity Center admin). Once it lapses, the CLI cannot mint role credentials for any profile tied to that session until you log in again.

Edge cases

• Multiple profiles can share one sso-session; refreshing the session fixes all of them at once.
• Adding sso_registration_scopes = sso:account:access to the session block enables automatic token refresh and cuts down on re-logins.
• Deleting ~/.aws/sso/cache forces a clean re-login if the cached token is corrupt.

Documented in the towardsthecloud AWS CLI profiles guide under 'SSO Token Expiration': the error 'The SSO session associated with this profile has expired or is otherwise invalid' means the Identity Center session ended, and the fix is 'aws sso login --profile my-sso-profile', or 'aws sso login --sso-session my-sso-session' when using named SSO sessions. The guide also notes the pro tip that SSO sessions with 'ssoregistrationscopes = sso:account:access' support automated token refresh, reducing how often re-authentication is needed. Source: https://towardsthecloud.com/blog/aws-cli-switch-profiles

Not specified by the original author.

Your temporary AWS credentials ran out. Run aws sso login --profile your-profile to get a fresh session, then retry the command. If you are not on SSO, mint new temporary credentials (STS) or re-export fresh ones. The error is expected behavior, not a misconfiguration.

An error occurred (ExpiredToken) when calling the ListBuckets operation: The security token included in the request is expired

Fix

1. If you use AWS IAM Identity Center (SSO), refresh the session:

   aws sso login --profile your-profile

   Expected: a browser window opens, you approve, and the CLI prints Successfully logged into Start URL.

2. Verify the fresh identity works:

   aws sts get-caller-identity --profile your-profile

   Expected: JSON with your UserId, Account, and Arn. No error.

3. If you use STS temporary credentials (not SSO), get new ones and update ~/.aws/credentials or your env vars, then retry.

4. If ExpiredToken appears immediately after a successful aws sso login, stale environment variables are overriding your profile. Check:

   env | grep AWS_

   If AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_SESSION_TOKEN are set, unset them:

   unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

   Expected: aws sts get-caller-identity --profile your-profile now works.

When this applies

• Any aws command fails with (ExpiredToken) and The security token included in the request is expired.
• You use aws sso login, assumed roles, get-session-token, or EC2/ECS task roles with cached creds.

When it does NOT apply

• InvalidClientTokenId or InvalidAccessKeyId: those mean the keys are wrong or revoked, not expired. Re-enter credentials with aws configure.
• AccessDenied: the credentials are valid but lack permission. That is an IAM policy problem.
• Unable to locate credentials: nothing is configured at all.

Compatibility

• AWS CLI v2 (all recent versions). SSO flow requires CLI v2; aws configure sso is not a v1 command.

Why it happens

Temporary credentials have a fixed lifetime. SSO sessions typically last 8-12 hours, assumed-role sessions 1-12 hours depending on configuration. When the clock runs out, every API call fails with ExpiredToken until you re-authenticate. The CLI caches role credentials in ~/.aws/cli/cache, so a revoked or expired cached session can also linger there.

Edge cases

• Clock skew: if your system clock is far off, tokens can look expired early. Sync with NTP.
• CI jobs longer than the session duration: refresh mid-job or use a longer session duration on the role.
• rm -r ~/.aws/cli/cache forces the CLI to drop cached role credentials and fetch fresh ones.

AWS CLI users hit this constantly with SSO and assumed-role sessions: temporary credentials expire by design (typically 1-12 hours depending on the session). Multiple troubleshooting guides document the same verified fix. The towardsthecloud AWS CLI profiles guide documents 'The security token included in the request is expired' with the fix 'Identity Center session ended, run aws sso login', and notes that if ExpiredToken appears immediately after a successful aws sso login, environment variables are overriding the profile (unset AWSACCESSKEYID, AWSSECRETACCESSKEY, AWSSESSIONTOKEN). The matthewduke1 aws-onboarding troubleshooting reference independently documents the same env-var override trap. For non-SSO temporary credentials (STS get-session-token, assumed roles), the fix is to mint fresh credentials. Source: https://towardsthecloud.com/blog/aws-cli-switch-profiles