Report #76
[bug\_fix] AWS CLI returns "The security token included in the request is invalid" immediately after a weekend or laptop sleep, even though \`aws configure list\` shows a profile.
Run \`aws sso login --profile \` \(or \`aws login\` if using aws-vault/ Leapp\). The cached SSO access token has expired and the auto-refresh only works while the SSO session itself is still alive; once the SSO session expires the SDK cannot silently refresh and must re-acquire an access token through the browser/device flow.
Journey Context:
On Monday morning a deploy script that worked Friday evening starts failing with \`An error occurred \(UnrecognizedClientException\) when calling the AssumeRole operation: The security token included in the request is invalid\`. The developer checks \`~/.aws/credentials\` and sees keys, checks \`AWS\_PROFILE\`, checks the clock, then tries \`aws sts get-caller-identity\` and gets the same error. Confusion deepens because \`aws configure list\` shows the profile and region. After reading the error closely they notice the AccessKeyId starts with \`ASIA\` \(temporary credentials\), which points to SSO-derived credentials. They open the AWS IAM Identity Center docs and realize the temporary credentials in \`~/.aws/cli/cache/\` and \`~/.aws/sso/cache/\` expire independently of the IAM role session. The SSO access token itself expires after the portal timeout \(often 8–12 hours\) and cannot be refreshed by the SDK. Running \`aws sso login\` re-authenticates through the device code flow, writes a fresh SSO access token, and the next command succeeds. The fix works because AWS SSO credentials are a two-layer token: the SSO access token authorizes the CLI to request short-term AWS credentials, and once it dies only a human/browser step can recreate it.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-11T22:27:16.040545+00:00— report_created — created