为了保护 REST API，访问控制的逻辑选择是 JWT 本身或与 OAuth 结合使用。如果我只关心对调用者进行身份验证，那么验证 JWT 签名本身就足够了。如果我也关心授权，我也会使用 OAuth 或某种令牌服务。无论哪种方式，我都会Authorization: Bearer [JWT token]在 HTTP 请求中包含一个标头。
AWS 有自己的 API 访问控制标准，您可以在其中签署请求本身的部分内容并包含如下标头
Authorization: AWS4-HMAC-SHA256 ....
我的问题：
AWS 方法对重放攻击是否更安全？我认为是的，因为即使您的令牌过期时间很短，假设仍然可以在不同的请求上重用不记名令牌。签名意味着请求没有被篡改。
如果它更安全，是否应该将其视为 OAuth 和 JWT 之类的行业标准？标准应用程序框架在多大程度上提供了验证方面的支持？等等。
AWS 方法对重放攻击是否更安全？我认为是的，因为即使您的令牌过期时间很短，假设仍然可以在不同的请求上重用不记名令牌。签名意味着请求没有被篡改。
是的，它对重放攻击更安全。正如您所建议的，不记名令牌可以用于任何请求（不仅仅是理论上）。他们完全独立于他们授权的请求。另一方面，AWS 签名“绑定”到它们所附加的请求。签名的请求还包含由 AWS 检查以确保它在特定窗口内的时间戳。该请求只能在此窗口中重放。
正如您所说，签名确保请求的完整性。HTTPS 也提供了完整性。即使取消了 HTTPS，AWS 方案也能保持完整性。
如果它更安全，是否应该将其视为 OAuth 和 JWT 之类的行业标准？标准应用程序框架在多大程度上提供了验证方面的支持？等等。
它确实为您提供了更多的安全属性。还有一些其他 HTTP 签名方案试图复制 AWS 所做的事情。这是一个草稿。Joyent 还创建了自己的方案。还有一个名为Escher的库，它完全复制了 AWS 方案。它也与它兼容，并且还包括验证方面。
免责声明：我为开发 Escher 的公司工作。我们在生产中使用它来连接许多服务。
AWS 方法对重放攻击是否更安全？我认为是的，因为即使您的令牌过期时间很短，假设仍然可以在不同的请求上重用不记名令牌。签名意味着请求没有被篡改。
使用 API 发送的所有请求都有一个与之关联的时间戳。AWS 拒绝在时间戳超过 5 分钟后收到的请求。对于 5 分钟内的回放，他们可以简单地维护一个缓存请求的滑动窗口。它可以将哈希与缓存中的哈希匹配并检测重放。
如果它更安全，是否应该将其视为 OAuth 和 JWT 之类的行业标准？标准应用程序框架在多大程度上提供了验证方面的支持？等等。
如果您正在谈论散列请求并将散列与请求一起发送的基本概念，那么这就是已经完成的事情。我觉得亚马逊在这里使用的系统受到了 Kerberos 系统的启发，该系统具有类似的检测重放攻击的机制以及散列请求并附加它以确保它在途中不被篡改的想法。