DynoTable

The security token included in the request is expired

TL;DR — 你的临时 AWS 凭证超时了。这只发生在 STS/SSO/担任角色的凭证上（不是长期的 IAM 用户密钥）。刷新会话——重新运行 aws sso login 或重新担任角色——确保 AWS_SESSION_TOKEN 是新的那个，并清除环境中残留的任何陈旧 token。

含义

ExpiredTokenException: The security token included in the request is expired

AWS 拒绝了你的请求，因为签名它所用的临时安全凭证已经过期。来自 STS（AssumeRole、SSO、GetSessionToken、EC2/ECS 实例角色）的临时凭证存活于一个有界的窗口——角色会话从 15 分钟到角色的最大会话时长设置（在 1 到 12 小时之间；默认 1 小时），而一个 IAM 用户的 GetSessionToken 凭证默认 12 小时，可延长到 36 小时。一旦那个窗口过去，用它们签名的每个请求都会以 ExpiredTokenException 失败。用同一个过期 token 重发会再次失败——只有在你刷新之后重试才值得。

为什么会发生

  • STS/SSO 会话干脆超时了——担任角色的凭证在角色的会话时长（默认 1 小时，可配置到 12 小时）到期；一个 SSO 会话同样会过期。
  • 环境中一个陈旧的 AWS_SESSION_TOKEN——一个导出到你 shell（或一个 .env）中的旧会话 token 在它过期后仍被继续使用；环境变量不会自动刷新。
  • 一个长时间运行的进程在启动时获取了一次凭证却从不刷新它们。
  • 缓存的凭证在 ~/.aws/cli/cache 或一个 SDK 凭证缓存中超过了它们的到期时间。
  • 时钟偏移——一台时钟偏得够远的机器可能让有效凭证看起来过期。

如何修复

  1. 刷新会话。 重新运行 aws sso login（对 SSO）或重新担任角色（aws sts assume-role …），获取一个新的访问密钥、密钥和会话 token。
  2. 一起更新全部三个值——访问密钥 ID、密钥访问密钥，以及会话 token。一个新密钥配上一个陈旧的 token 仍会失败。
  3. 清除陈旧的环境变量——unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN，然后重新加载新凭证或切换到一个 SDK 能自行刷新的 profile。
  4. 让 SDK 管理生命周期——配置一个 profile / 凭证提供者（SSO、assume_role、实例角色），让 SDK 在到期前自动刷新，而不是固定一个 token。
  5. 用 aws sts get-caller-identity 核实——如果它成功，你的凭证就是当前的。
  6. 检查时钟（NTP），如果一切看起来都是新的但请求仍报告过期。

从 DynoTable 连接

DynoTable 会在每次连接时重新解析你的配置文件 —— 包括 SSO 会话 和受 MFA 保护的 assume-role —— 所以只要会话续上了，你的表不用重启就会回来。临时凭证 过期时，配置文件徽标上的状态点会变红，并显示登录（SSO）或重新连接；点它，或者 重新跑一次查询，就会触发应用内的刷新流程。按 ⌘P 确认你处在刚才在终端里刷新 过的那个配置文件上。刷新之后，查询构建器是一个快速的 健全性检查，能确认签名读取确实成功了。

常见问题

如何修复“请求中包含的安全令牌已过期”？ 你的临时凭证已过期。刷新它们 — 重新运行 aws sso 登录或重新承担角色 — 并一起更新访问密钥、密钥和 AWS_SESSION_TOKEN。清除 shell 中残留的所有过时令牌，以便旧令牌不会被重复使用，并且更喜欢自动刷新的 SDK 凭据提供程序。

为什么我只能通过临时凭证才能获得此信息？ ExpiredTokenException 适用于有时间限制的 STS/SSO/假定角色凭证，这些凭证带有过期时间。长期存在的 IAM 用户访问密钥不会自行过期，因此它们会因其他原因（无效/禁用）而不是此原因引发凭证错误。

相关错误

来源

无需控制台即可使用 DynamoDB

一款快速的 DynamoDB 桌面客户端，可运行 DynamoDB 无法执行的真正 SQL——JOINs、GROUP BY、聚合——并支持可视化编辑和运行在你自己的 Bedrock 密钥上的 AI agent。

下载查看定价

30 天免费试用，无需信用卡 — 之后为无时间限制的免费版。