我正在测试的移动应用程序的 API 正在发送用于从未加密的 AWS Cognito 服务器签署请求的 AWS AccessKeyId 和 SecretKey（除了常规的 TLS 加密）。可以将所有请求重新签名到他们的 AWS Lambda API，例如使用 Burp 的“AWS Signer”扩展。
有了这个，中间人可以签署所有更改的请求，所以我想知道在这种情况下请求签名的实际用例是什么？
AccessKeyID 和 SecretKey 不应该保密吗？
该应用程序的所有者告诉我这不是问题，因为他们遵循 AWS 指南。
那是对的吗？还是他们做错了什么？
他们为什么会首先在他们的移动应用程序中签署请求？当创建签名的“秘密”通过相同的连接以明文方式分发（TLS 除外）时，签署请求的用例是什么？
在将 AWS Lambda 用于无服务器移动应用程序 API 时，这是否符合最佳实践？在这种情况下，请求签名甚至有用吗？我测试过的大多数应用程序都没有使用请求签名。
你说得对。移动应用程序开发人员不正确。没有理由分享 SecretKey。
事实上，他们不应该将它与应用程序一起发布。
TL;博士;
这里有一个适用于安全性的工程原理 - 亲吻或保持简单，先生。
阅读 AWS 文档并请求安全性，很明显他们会通过精心设计的方法来保持访问密钥的私密性，并且不希望您共享它。
您所说的请求签名是让 AWS 确定知道 SECRET 的人是否实际发送了请求的一种精心设计的方式。如果他们也发送秘密，那么是的，任何 MITM 都可以拦截并“证明”他们也持有秘密，因为他们显然这样做了。
回到 KISS 原则——在这种情况下，原则是永远不要分享秘密。就是这么简单。
AccessKeyID 和 SecretKey 不应该保密吗？
据此：_
是的，他们应该保密。
有了这个，中间人可以签署所有更改的请求，所以我想知道在这种情况下请求签名的实际用例是什么？
据此_
AWS 访问密钥 ID 是唯一用户/账户标识符的一种形式
和
AWS 密钥就像私钥
所以签名是一种验证\识别用户的方式
他们为什么会首先在他们的移动应用程序中签署请求？当创建签名的“秘密”通过相同的连接以明文方式分发（TLS 除外）时，签署请求的用例是什么？
他们设计成这样的原因我们永远不会知道，但是以明文形式发送如此敏感的信息并不是一个好主意。然而，根据这个
请求不是使用密钥本身签名的，而是使用使用密钥生成的签名密钥。它还使用 HMAC-SHA256 进行签名。
因此，AWS 最新的身份验证机制根本不会接受密钥。它基于上述方式对 API 请求进行身份验证。