The security token included in the request is expired

TL;DR — Your temporary AWS credentials timed out. This only happens with STS/SSO/assumed-role credentials (not long-lived IAM user keys). Refresh the session — re-run aws sso login or re-assume the role — make sure AWS_SESSION_TOKEN is the fresh one, and clear any stale token left in the environment.

What it means

ExpiredTokenException: The security token included in the request is expired

AWS rejected your request because the temporary security credentials it was signed with have expired. Temporary credentials from STS (AssumeRole, SSO, GetSessionToken, EC2/ECS instance roles) live for a bounded window — 15 minutes to 12 hours depending on the role's session duration. Once that window passes, every request signed with them fails with ExpiredTokenException (HTTP 400). It's retryable only after refreshing — resending with the same expired token fails again.

Why it happens

  • The STS/SSO session simply timed out — assumed-role credentials last 1–12 hours (the role's max session duration); an SSO session likewise expires.
  • A stale AWS_SESSION_TOKEN in the environment — an old session token exported into your shell (or a .env) keeps being used after it expired; env vars don't auto-refresh.
  • A long-running process that fetched credentials once at startup and never refreshed them.
  • Cached credentials in ~/.aws/cli/cache or an SDK credential cache that outlived their expiry.
  • Clock skew — a machine clock far enough off can make valid credentials look expired.

How to fix it

  1. Refresh the session. Re-run aws sso login (for SSO) or re-assume the role (aws sts assume-role …) to get a new access key, secret, and session token.
  2. Update all three values — access key id, secret access key, and the session token together. A fresh key with a stale token still fails.
  3. Clear stale env varsunset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, then re-source the fresh credentials or switch to a profile the SDK can refresh on its own.
  4. Let the SDK manage the lifecycle — configure a profile / credential provider (SSO, assume_role, instance role) so the SDK auto-refreshes before expiry instead of pinning one token.
  5. Verify with aws sts get-caller-identity — if that succeeds, your credentials are current.
  6. Check the clock (NTP) if everything looks fresh but requests still report expiry.

FAQ

How do I fix "the security token included in the request is expired"? Your temporary credentials expired. Refresh them — re-run aws sso login or re-assume the role — and update the access key, secret, and AWS_SESSION_TOKEN together. Clear any stale token left in your shell so the old one isn't reused, and prefer an SDK credential provider that refreshes automatically.

Why do I only get this with temporary credentials? ExpiredTokenException applies to time-bounded STS/SSO/assumed-role credentials, which carry an expiry. Long-lived IAM user access keys don't expire on their own, so they raise credential errors for other reasons (invalid/disabled), not this one.

Trabaja con DynamoDB sin la Consola

DynoTable es un cliente de escritorio rápido para DynamoDB: explora tablas, ejecuta consultas estilo SQL y edita Items localmente.