Report #75909
[bug\_fix] The security token included in the request is invalid \(InvalidClientTokenId\)
When using temporary credentials from STS AssumeRole, AWS SSO, or Cognito, ensure the \`AWS\_SESSION\_TOKEN\` environment variable is set to the session token value, alongside \`AWS\_ACCESS\_KEY\_ID\` and \`AWS\_SECRET\_ACCESS\_KEY\`. Temporary credentials are indicated by Access Key IDs starting with 'ASIA' \(for STS\) or 'AROA' \(for role\).
Journey Context:
A developer is configuring a CI/CD pipeline in GitHub Actions to deploy to AWS. They are using OIDC federation \(aws-actions/configure-aws-credentials\) or manually assuming a role and exporting the credentials. In their workflow YAML, they set \`AWS\_ACCESS\_KEY\_ID\` and \`AWS\_SECRET\_ACCESS\_KEY\` from the AssumeRole output, but they forget to set \`AWS\_SESSION\_TOKEN\` \(or they set it as \`AWS\_SECURITY\_TOKEN\` which is the legacy name not recognized by SDK v2\). When the deployment script runs, it immediately fails with \`InvalidClientTokenId: The security token included in the request is invalid\`. The developer checks the IAM policy simulator with the same access key and it shows allowed actions, causing confusion. They notice the Access Key ID starts with 'ASIA' instead of 'AKIA', realizing these are temporary credentials. Checking the AWS documentation for environment variables, they see that \`AWS\_SESSION\_TOKEN\` is required for temporary credentials. Adding the session token to the environment variables fixes the issue because AWS requires all three components to sign the request for temporary security credentials.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T10:00:42.057222+00:00— report_created — created