ExpiredToken
This error occurs when the temporary security credentials provided by AWS STS (or AWS SSO/Identity Center) have expired.
Usually happens because:
- ☑ AWS IAM Identity Center (SSO) login token has expired
- ☑ Assumed STS role session duration limit has been exceeded
- ☑ Host node clock drift causes AWS gateway signature validation failures
🔍 Quick Checklist:
What is ExpiredToken?
An 'ExpiredToken' (or 'RequestExpired') error is raised when temporary security credentials generated by AWS Security Token Service (STS) or AWS IAM Identity Center exceed their expiration duration limit (standard lifespan spans from 15 minutes to 36 hours). Once expired, any subsequent API calls using the session token will be rejected by the AWS gateway.
Common Causes
- Expired CLI/SDK session profile: AWS IAM Identity Center (SSO) login token or MFA session credentials have timed out.
- Assumed Role duration limit exceeded: The session credentials generated by 'sts:AssumeRole' have expired before the long-running script completed.
- System clock drift on client machine: Local machine system clock differs from AWS standard time, causing AWS to reject valid session tokens.
| Cause | Frequency |
|---|---|
| Expired AWS IAM Identity Center (SSO) login session (usually 8-12 hours) | ⭐⭐⭐⭐⭐ |
| Assumed IAM Role token lease timeout (default 1 hour limit) | ⭐⭐⭐⭐ |
| Client system clock drift causing premature token expiration | ⭐⭐⭐ |
Common Mistakes
- Hardcoding `AWS_SESSION_TOKEN` inside continuous integration pipeline files (CI/CD workflows) where tokens decay quickly, locking builds out.
- Neglecting to adjust the IAM Role's Maximum CLI/API session duration attribute when requesting long role sessions (up to 12 hours) in STS calls.
How to Fix
AWS Operations & Verification
Configure the AWS CLI profile to utilize IAM Identity Center (SSO) credentials with automatic token cache refresh managers.
[profile developer-sso]
sso_session = my-sso-session
sso_account_id = 123456789012
sso_role_name = DeveloperPowerUser
region = us-west-2
[sso-session my-sso-session]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-west-2
sso_registration_scopes = sso:account:accessPlatform Specific Fixes
Inspect cached SSO tokens and refresh credentials using the CLI.
# 1. List cached credentials files
ls ~/.aws/cli/cache/
# 2. Check local system time synchronization
timedatectl statusBest Practices
- Configure credentials provider chains inside SDK apps to auto-renew session certificates.
- Adopt AWS IAM Identity Center instead of long-lived access credentials profiles.
Frequently Asked Questions (FAQ)
Q: What is an ExpiredToken error?
This means the temporary access keys (AccessKeyId, SecretAccessKey, and SessionToken) you are using to authenticate were generated by AWS STS but have now expired. You need to get a new set of keys.
Q: How do I refresh credentials when using AWS IAM Identity Center (SSO)?
Simply run: 'aws sso login'. This opens your browser to authenticate. Once logged in, the AWS CLI automatically updates your temporary credentials cache.
Q: Why do assumed roles expire after 1 hour?
When you call 'sts:AssumeRole', the default session duration is 1 hour. If your application runs longer than this, you get an ExpiredToken error. You can specify a higher '--duration-seconds' value (up to 43200 seconds / 12 hours) when assuming the role, provided the role itself is configured to allow that duration.
Q: How does clock drift cause this error?
AWS compares the signature timestamp on your request with its own server time. If your local system clock drifts by more than 5 minutes, AWS rejects your request, often showing an ExpiredToken or invalid signature error.