How to Fix AWS Authentication Errors (InvalidClientTokenId, ExpiredTokenException, SignatureDoesNotMatch)

Quick fix checklist

Work through this sequence in order:

1. Run the identity check:

   aws sts get-caller-identity

2. Check for stale environment variables. These override everything else, including --profile flags:

   echo $AWS_ACCESS_KEY_ID
   echo $AWS_PROFILE
   # Clear them if they are wrong:
   unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

3. Check whether you need a session token. Access key IDs starting with ASIA are temporary. Setting only the key ID and secret key is not enough. You must also export AWS_SESSION_TOKEN.

4. Refresh your SSO session if you use IAM Identity Center:

   aws sso login --profile your-sso-profile

5. Check your system clock if you see SignatureDoesNotMatch with keys that look correct. AWS rejects requests with a timestamp more than 15 minutes off.

6. Re-assume the role if you see ExpiredTokenException in a CI/CD job or long-running script.

Simple explanation

When you run an AWS CLI command, AWS answers two questions in sequence:

1. Who are you? (authentication)
2. Are you allowed to do this? (authorization)

Authentication errors happen at step 1. AWS is not saying you lack permission. It is saying it cannot verify your identity at all.

Here is how the three credential types map to that analogy:

If any required piece is wrong, missing, or expired, AWS returns an authentication error.

For a deeper look at how access keys and temporary credentials differ, see Access Keys Explained and STS Temporary Credentials.

How AWS authentication works for CLI and SDK requests

The AWS CLI and all AWS SDKs use a credential provider chain: a prioritised list of places to look for credentials. The first source that returns a complete credential set wins.

The standard order is:

1. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN
2. AWS_PROFILE environment variable: points to a named profile in ~/.aws/credentials or ~/.aws/config
3. Default profile: the [default] section in ~/.aws/credentials / ~/.aws/config
4. AWS SSO / IAM Identity Center: if the active profile is configured for SSO
5. ECS container credentials: AWS_CONTAINER_CREDENTIALS_RELATIVE_URI (set automatically for ECS task roles)
6. EC2 instance metadata: http://169.254.169.254/... (set automatically for EC2 instance profiles and Lambda execution roles)

Why ASIA credentials without a session token always fail: Temporary credentials are not just a key pair. An ASIA access key ID without its session token is meaningless to AWS. All three parts must come from the same AssumeRole or GetSessionToken response.

Why sessions expire: When you call sts:AssumeRole or log into IAM Identity Center, AWS issues a credential set with an embedded expiry timestamp. AWS checks that timestamp on every request. Once it passes, every call returns ExpiredTokenException. There is no extension — you re-assume the role to get a fresh set.

For how roles and trust policies control who can assume what, see Role Assumption in AWS and IAM Roles Explained.

Error quick-reference table

Troubleshooting specific AWS authentication errors

InvalidClientTokenId

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation:
The security token included in the request is invalid.

What it means: The access key ID is not recognised by AWS. This is not a permissions problem. AWS cannot match the key ID to any valid credential set at all.

Most likely causes:

• You are using an ASIA temporary key without providing AWS_SESSION_TOKEN
• The access key was deleted from IAM (or the IAM user was deleted)
• The key ID is mistyped, truncated, or has extra whitespace
• The key belongs to a different AWS account than the endpoint you are calling

How to diagnose:

# Confirm what key ID is actually being used
aws sts get-caller-identity 2>&1

# Check what is in your environment
echo "Key ID: $AWS_ACCESS_KEY_ID"
echo "Session token set: $([ -n "$AWS_SESSION_TOKEN" ] && echo yes || echo no)"

# Check how the active profile is configured
aws configure list

Fixes:

• If the key starts with ASIA: export all three variables from the same AssumeRole response
• If the key starts with AKIA and is not recognised: re-create the access key in IAM and reconfigure with aws configure
• Unset stale environment variables that may be shadowing a working profile

SignatureDoesNotMatch

An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation:
The request signature we calculated does not match the signature you provided.

What it means: The key ID is recognised, but the secret access key does not match it, or the request timestamp is too far from AWS server time.

Most likely causes:

• Wrong secret access key: extra whitespace on paste, truncated, or a line break included
• Access key ID and secret access key swapped (the ID is AKIA..., not the secret)
• System clock more than 15 minutes off from UTC

How to diagnose:

# Compare your system time against AWS server time
date -u
curl -sI https://aws.amazon.com 2>/dev/null | grep -i "^date:"

# Verify both fields are filled in for the active profile
aws configure list --profile your-profile-name

Fixes:

• Re-paste the secret access key carefully: select the full value with no surrounding whitespace
• Confirm you have not swapped key ID and secret
• Sync your system clock:

# Linux (systemd)
sudo timedatectl set-ntp true

# Linux (ntpd)
sudo ntpdate pool.ntp.org

# macOS
sudo sntp -sS time.apple.com

ExpiredTokenException

An error occurred (ExpiredTokenException) when calling the DescribeInstances operation:
The security token included in the request is expired.

What it means: Temporary credentials from STS have passed their expiry time. Every API call will return this error until you get a fresh credential set.

Most likely causes:

• AssumeRole credentials used beyond their session duration (default: 1 hour)
• A script that exports STS output at job start and then runs longer than the credential duration
• Credentials exported as environment variables hours or days ago and left set

How to check the expiry time:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/my-role \
  --role-session-name debug \
  --query 'Credentials.Expiration'

Fix — re-assume the role and export fresh credentials:

CREDS=$(aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/my-role \
  --role-session-name my-session \
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
  --output text)

export AWS_ACCESS_KEY_ID=$(echo $CREDS | awk '{print $1}')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | awk '{print $2}')
export AWS_SESSION_TOKEN=$(echo $CREDS | awk '{print $3}')

For automation, the better fix is to stop holding credentials at all. See CI/CD and automation failure patterns below.

TokenRefreshRequired / token has expired

Error when retrieving credentials from sso: Token has expired and refresh failed

or:

An error occurred (TokenRefreshRequired) when calling the GetObject operation:
The provided token has expired.

What it means: An IAM Identity Center (SSO) session has expired. SSO sessions are browser-authenticated with a configurable duration, typically 8 hours. When the session ends, every profile that relied on that login stops working.

Fix:

# Log in again (opens a browser)
aws sso login --profile your-sso-profile

# Verify it worked
aws sts get-caller-identity --profile your-sso-profile

To check when the current SSO session expires:

cat ~/.aws/sso/cache/*.json | python3 -c "
import json, sys
for line in sys.stdin:
    try:
        data = json.loads(line)
        if 'expiresAt' in data:
            print('Expires at:', data['expiresAt'])
    except:
        pass
"

MFA-required authentication and session issues

Some IAM policies use a condition that requires MFA for sensitive operations:

{
  "Effect": "Deny",
  "Action": ["iam:DeleteUser", "iam:DeleteRole"],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

When a user without an active MFA session tries this action, they get AccessDenied with a message indicating MFA is required. The fix is to get a session token that carries MFA proof:

aws sts get-session-token \
  --serial-number arn:aws:iam::111122223333:mfa/alice \
  --token-code 123456 \
  --duration-seconds 3600

# Export the returned credentials
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

Then retry the operation. The session token embeds proof that MFA was present when it was issued.

When to use this page

This page is for you if:

• AWS CLI commands that were working suddenly return InvalidClientTokenId, SignatureDoesNotMatch, or ExpiredTokenException
• A CI/CD job fails with an authentication error partway through, especially if it starts fine and breaks hours later
• Your IAM Identity Center SSO session expired and commands are returning token errors
• You have multiple AWS accounts and suspect the wrong profile or account is active
• You copied temporary credentials into environment variables and they have stopped working
• You see SignatureDoesNotMatch and cannot figure out why when the keys look correct

This page is not for:

• AccessDenied errors where aws sts get-caller-identity succeeds: that is an authorization problem. See IAM AccessDenied Errors
• AWS Console browser login failures (password or MFA device issues)
• VPC or network connectivity problems: see Debugging VPC Connectivity

Authentication errors vs AccessDenied errors in AWS

These two failure types look similar in the terminal but have completely different causes and fixes.

The distinction matters because fixing authentication never involves IAM policies, and fixing authorization never involves credential rotation. Treating one as the other wastes time.

For auditing both types of failure in logs, see CloudTrail Overview.

CI/CD and automation failure patterns

Authentication errors in CI/CD almost always share the same root cause: a job that assumes a role once at start and holds those credentials longer than their session duration.

The classic scenario:

A deploy pipeline runs at midnight. It calls sts:AssumeRole at job start and exports the credentials. Deployment finishes in 20 minutes. A post-deployment health check runs at 4am — using credentials that expired at 1am. Every call returns ExpiredTokenException.

# The AssumeRole that caused the problem
aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/deploy-role \
  --role-session-name deploy \
  --query 'Credentials.Expiration'
# Returns: "2026-03-19T01:00:00Z" — expired 3 hours before the health check ran

Temporary fix: Have each stage that needs AWS access assume the role independently so each step gets its own fresh credentials.

Proper fix: Use a credential source that does not require manual rotation: