Report #70330
[bug\_fix] AWS CLI / SDK: "The security token included in the request is invalid" or "Unable to locate credentials" after a working SSO session suddenly starts failing
Re-authenticate with the correct SSO profile: \`aws sso login --profile \` \(or \`aws sso login\` if you rely on the default profile\). If running in a shell script or CI, switch to long-lived IAM user keys or an IAM role with \`aws sts assume-role\` and export the returned \`AWS\_ACCESS\_KEY\_ID\`, \`AWS\_SECRET\_ACCESS\_KEY\`, and \`AWS\_SESSION\_TOKEN\` before they expire.
Journey Context:
You ran \`aws s3 ls\` successfully this morning, but now every call returns "The security token included in the request is invalid." You first check \`~/.aws/credentials\` and see entries, so you assume the keys are present. You try exporting \`AWS\_PROFILE\` and \`AWS\_REGION\` but the error persists. Digging into \`~/.aws/sso/cache/\`, you notice the JSON token file has an \`expiresAt\` that passed an hour ago. The root cause is that AWS SSO sessions are temporary: the SSO token cached by \`aws sso login\` expires \(often in hours, configurable by the SSO provider\), and the short-term credentials auto-generated from that token expire even sooner. The AWS CLI/SDK silently uses expired cached credentials instead of re-prompting. Running \`aws sso login\` forces a browser/device-code refresh of the SSO token and re-creates valid short-term credentials under the profile. For unattended automation, the correct fix is not to keep re-running \`aws sso login\`; it is to use IAM user keys or, better, assume an IAM role via STS and rotate the session tokens before expiry.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T00:38:08.669542+00:00— report_created — created