ExpiredToken
AWS ExpiredToken (Expired Token) means the provided token has expired. In Amazon S3, this error returns HTTP 400.
Last reviewed: April 21, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Expired Token Mean?
AWS recognized the temporary credential type, but the session token attached to the request has already expired. Authentication fails before the target service evaluates the operation, so the fix lives in credential lifetime, refresh timing, and dispatch delay rather than permissions.
Common Causes
- -STS temporary credentials expired before the request reached AWS.
- -Long-running workers reuse cached tokens past credential expiration.
- -Queue/backoff delays push signed requests beyond token validity window.
- -Presigned URLs created from temporary credentials outlive the underlying session token that signed them.
- -Credential provider refresh path breaks or loses metadata-server access, so the runtime keeps serving stale tokens.
- -Clock drift makes tokens appear expired earlier than expected.
How to Fix Expired Token
- 1Refresh credentials from STS/role provider and retry with new session token.
- 2Verify the runtime can still reach its credential provider or metadata endpoint before assuming the refresh happened.
- 3Reduce time between token acquisition, request signing, and request dispatch.
- 4Synchronize system clocks and verify UTC time source health.
- 5Refresh tokens before hard expiration and invalidate stale credential caches after rotation or runtime resume.
Step-by-Step Diagnosis for Expired Token
- 1Capture token expiration timestamp and compare with request execution timestamp.
- 2Trace credential provider chain to verify which session token was actually used.
- 3Check whether refresh attempts are failing because metadata, web identity, or role-assumption paths are unavailable.
- 4Inspect queue latency/retry delays between token minting and API transmission.
- 5Verify whether presigned URLs were generated from temporary credentials whose session expired earlier than the URL TTL suggests.
- 6Correlate auth failures with node clock skew metrics across the fleet.
Seen in Production
- -A batch worker assumes role once at startup, runs for hours, and only starts failing with
ExpiredTokenafter the first credential lifetime boundary passes. - -IRSA or ECS task-role refresh breaks when metadata or token file access regresses, so pods keep serving stale credentials long after the provider should have rotated them.
- -A presigned S3 URL is shared for several hours, but it was generated from 1-hour temporary credentials, so users start seeing ExpiredToken before the visible URL TTL ends.
- -Incident retries stretch queue dwell time so long that the request is finally sent after the original session token lifetime already ended.
Session Lifetime and Refresh Path Audit
- -Inspect token issue/expiry timestamps from the active credential provider (example: worker reuses 60-minute STS session for a 2-hour batch).
- -Trace where credentials are cached and reused across processes (example: sidecar cache serves expired session token after provider refresh).
- -Verify the refresh path itself is healthy (example: metadata endpoint or web identity exchange fails, so the runtime never acquires the replacement token set).
Queue Delay, Signing Delay, and URL Lifetime
- -Measure delay between credential minting, request signing, and wire send (example: queue dwell time exceeds remaining token lifetime).
- -Compare presigned URL TTL to the underlying session-token lifetime (example: URL says 6 hours, but the STS session behind it expires in 1 hour).
- -Audit host/container clock drift against reliable UTC source (example: node runs 7 minutes behind and treats valid tokens as expired).
Decision Shortcut: Hard Expiry vs Wrong Credential Source
- -If the runtime immediately succeeds after refreshing the same role or session, stay in the ExpiredToken branch before debugging IAM policies.
- -If the token is not actually expired but the runtime is using an unexpected account or key chain, switch to InvalidClientTokenId or source-precedence debugging instead.
- -If presigned URLs fail for end users long before their visible expiry, inspect the underlying temporary credential lifetime first.
Wrong Fix to Avoid
- -Do not broaden IAM permissions when AWS is rejecting an expired session before authorization starts.
- -Do not keep retrying with the same stale token or presigned URL; a fresh credential set is required.
- -Do not only increase queue timeouts if the credential lifetime budget remains shorter than the real request path.
Implementation Examples
2026-04-15T10:02:14Z worker=invoice-batch requestId=req_51da3f
credentialExpiration=2026-04-15T10:00:00Z requestSentAt=2026-04-15T10:02:14Z
error=ExpiredToken message="The provided token has expired."env | rg '^AWS_'
aws sts get-caller-identity --debug 2>&1 | rg 'ExpiredToken|credential|AssumeRole'date -u
jq -r '.Credentials.Expiration // .Expiration' /tmp/aws-credentials-cache.jsonIncident Timeline
09:00 UTC
The runtime acquires a temporary session and starts healthy
Signal: A worker, pod, CI runner, or presigner obtains STS or role-based credentials and signs requests successfully at the start of the run.
Why it matters: At this point the key question is not whether the role exists, but whether the runtime will refresh before the session ends.
09:47 UTC
Queueing or long-lived execution consumes most of the remaining credential lifetime
Signal: Backlog, retries, pause-resume behavior, or missing refresh pushes requests close to or beyond the token expiration timestamp.
Why it matters: ExpiredToken incidents are often lifetime-budget bugs before they are permission bugs.
10:02 UTC
Blind retries reuse the same stale token
Signal: The runtime resends requests with the already-expired token or keeps handing out presigned URLs rooted in the same dead session.
Why it matters: Retries amplify the outage until the credential provider actually refreshes and the request is re-signed.
10:08 UTC
The refresh path is restored and fresh sessions clear the failure
Signal: Metadata access, web identity exchange, or assume-role refresh succeeds, and the same operation works with newly issued credentials.
Why it matters: That confirms the incident lived in session lifetime or refresh timing rather than IAM authorization.
Seen in Production
Background workers reuse STS credentials across long batch windows
Frequency: common
Example: Token issued at job start expires midway and subsequent calls fail with ExpiredToken.
Fix: Refresh credentials per batch segment and re-sign requests with current tokens.
Refresh path breaks after metadata or web identity regression
Frequency: common
Example: Pods should rotate role credentials automatically, but token exchange failures leave one deployment serving stale sessions until ExpiredToken spikes.
Fix: Restore metadata or web identity reachability and fail fast when refresh cannot complete.
Presigned URL lifetime exceeds underlying temporary session lifetime
Frequency: medium
Example: Users receive a multi-hour upload URL, but the assumed-role credentials behind it expire far earlier and S3 returns ExpiredToken.
Fix: Bind URL lifetime to the shorter session lifetime or reissue URLs from fresh credentials when needed.
Queue delay spikes during incident push requests past token lifetime
Frequency: medium
Example: Messages signed early are processed late and rejected as expired at execution time.
Fix: Sign as late as possible and cap queue dwell time for token-bound requests.
Wrong Fix vs Better Fix
Retry stale tokens vs refresh and re-sign
Wrong fix: Keep retrying the same request because the failure looks transient.
Better fix: Acquire a fresh temporary credential set, then re-sign and replay the request from the failing runtime.
Why this is better: ExpiredToken is deterministic for a dead session. Recovery begins only after the runtime is holding a valid token again.
Stretch queue timeouts vs shorten credential age
Wrong fix: Increase queue dwell or retry windows without checking session lifetime.
Better fix: Reduce acquisition-to-send delay, refresh earlier, or increase role session duration only if the workload genuinely needs it.
Why this is better: More delay often makes the token age problem worse unless credential lifetime and dispatch timing are redesigned together.
Verify locally only vs verify inside the failing runtime
Wrong fix: Test from an admin shell with fresh credentials and assume the incident is gone.
Better fix: Replay the exact workload path that failed and prove the original runtime now refreshes and uses the new session correctly.
Why this is better: Local success only proves one credential source works somewhere. The incident closes when the failing runtime refreshes successfully.
Debugging Tools
- -Credential expiration telemetry
- -AWS CLI --debug
- -STS provider logs
- -Metadata or web-identity refresh logs
- -Clock skew monitoring
How to Verify the Fix
- -Replay the same workflow and confirm ExpiredToken no longer appears.
- -Verify a forced refresh cycle completes successfully before the next credential expiration boundary.
- -Validate refreshed credentials map to expected account and principal.
- -Confirm presigned URLs minted from temporary credentials remain usable only within the shorter of URL TTL and session-token lifetime.
- -Confirm token-expiry auth failures trend down after refresh policy changes.
How to Prevent Recurrence
- -Implement proactive token refresh with safety margin before expiry.
- -Use centralized credential providers instead of ad hoc token caching.
- -Expose credential expiration and refresh-success metrics from every runtime that depends on temporary sessions.
- -Avoid generating long-lived user flows from short-lived temporary credentials unless refresh/reissue is built into the path.
- -Alert on near-expiry credential usage and clock-skew anomalies.
Pro Tip
- -refresh STS sessions based on remaining lifetime threshold (for example, 15 minutes) rather than fixed wall-clock intervals to avoid fleet-wide expiry spikes.
Decision Support
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.