X-Amz-Expires 是向 AWS 请求的必需标头/参数吗？

Question

1. X-Amz-Expires 是必需的标头/参数吗？官方文档不一致，在some examples中使用，而不在others中使用。

2. 如果不需要，签名请求的默认过期值是多少？它是否等于X-Amz-Expires 参数的最大可能值，即604800 (seven days)？

3. 文档（参见上面的链接）仅在查询字符串中传递签名参数的上下文中讨论 X-Amz-Expires 参数。如果需要X-Amz-Expires参数，是否只需要在查询字符串中传递签名参数（而不是使用授权标头传递它们）？

---

更新：

Introduction to AWS Security Processes 论文，第 17 页说

请求必须在 15 分钟内到达 AWS 请求中的时间戳。否则，AWS 将拒绝该请求。

现在我们在这里谈论的是什么时间戳？我的猜测是X-Amz-Date。如果我是对的，那么就会出现另一个问题：

4. X-Amz-Date 和X-Amz-Expires 参数如何相互关联？对我来说，如果 X-Amz-Expire 不存在，请求过期算法会从 X-Amz-Date 时间戳回退到 15 分钟。

Answer 1

X-Amz-Expires 是必需的标头/参数吗？

X-Amz-Expires 仅与查询字符串身份验证一起使用，而不与 Authorization: 标头一起使用。

查询字符串身份验证没有默认值。它是一个必填参数，如果查询字符串中存在X-Amz-Algorithm=AWS4-HMAC-SHA256 而不是X-Amz-Expires=...，服务将拒绝请求。

<Error>
  <Code>AuthorizationQueryParametersError</Code>
...

---

现在我们在这里谈论的是什么时间戳？

当与Authorization: 标头一起使用时，这是指X-Amz-Date:。因为X-Amz-Date: 是签名算法输入的一部分，所以更改日期或时间也会更改签名。早于或晚 1 秒签名的其他相同请求具有完全不同的签名。 AWS 本质上允许您的服务器时钟最多出错 15 分钟，而不会破坏您对请求进行身份验证的能力。它不是后备或默认设置。这是一个固定的窗口。

Authorization: 基于标头的请求中的 X-Amz-Date: 由 AWS 与它们的系统时间进行比较，这当然与 UTC 同步，如果该值偏离 15 分钟以上，则请求将被拒绝请求到达时的 UTC。在时间检查之前不会发生与身份验证相关的其他验证。

Query String认证过期的验证涉及到不同的逻辑：

• X-Amz-Expires 不能是大于 604800 或小于 0 的值；否则请求会立即被拒绝，无需进一步处理，包括类似于上述消息的消息。
• 根据 AWS 系统时钟，X-Amz-Date 未来不得超过 15 分钟。错误是Request is not yet valid。
• X-Amz-Date 不得超过 X-Amz-Expires 过去的秒数，相对于 AWS 系统时钟，并且不适用 15 分钟容差。错误是Request has expired。

如果出现上述任何一种情况，则不会对签名进行进一步验证，因此这些消息不会根据签名的有效性而改变。这是首先检查的。

此外，X-Amz-Date: 最左边的 8 个字符必须与 Authorization: 标头的 Credential 组件的日期部分匹配。日期本身对与凭证的差异零容忍（因此，在签名时，不要两次读取系统时间，否则您可能会在 UTC 午夜前后偶尔生成无效签名）。

最后，请求在处理过程中不会过期。如果您使用任一签名方法发送请求，该请求在到达时被视为有效，但此后很快就会过期，则始终允许它运行到完成——例如，大型 S3 下载或 EBS 快照创建请求将不会启动，然后无法继续，因为在 AWS 端已经开始请求时到期计时器已触发。如果该操作在请求时被授权，则它会继续并正常成功。