用例： 我们有一些 AWSGateway API，我们的客户可以使用它们在后端做一些事情。这些 API 受 Cognito 保护。目前，我们的客户通过使用 Cognito 移动 SDK 构建的 android 应用程序使用此 APIS。
现在我们正尝试将这些 API 公开给我们的客户，以便集成到他们的内部工作流程中。
我试图找到最好的方法来做到这一点。目前我无法找到有关如何执行此操作的任何资源。
我似乎是 AWS Cognito 的服务器端用户，但我认为这不是我们想要做的。
谢谢。
【问题讨论】：
标签： rest amazon-web-services api aws-api-gateway amazon-cognito
我猜这将是服务到服务或（服务器到服务器）通信，因为使用的这个术语是 Oauth 标准是 client_credentials 授权类型。
请参考文档获取token
获取令牌后，您需要传递此令牌Authorization 或API Gateway Custom Header for AWS Cognito。
【讨论】：
为了正确回答您的问题，我们需要更多信息。
SDK 或没有 SDK
您可以通过生成的 SDK 或您自己的代码访问 API Gateway 中的网络服务。 从 API Gateway 控制台生成 SDK 的说明位于 here。
使用身份验证调用 Web 服务可以通过 IAM、API 密钥、Cognito、自定义授权者四种方式完成。我将提到前三个。
IAM
IAM 政策示例：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::account-id:user/Alice",
"account-id"
]
},
"Action": "execute-api:Invoke",
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage/GET/pets"
]
}
]
}
将此角色分配给您创建的用户。策略示例可用here.。有关包括本地证书等的更多身份验证选项，请查看here。
API 密钥
如果您向 API 添加密钥，移动应用程序将失败，因为它没有这些密钥。最好部署一个不同版本的 API，它可以包装现有的 API，可以提供特定于工作流的附加功能。要了解如何执行此操作，请关注此link。
API 密钥的优点是您可以限制对 API 网关功能的访问、随意删除密钥、回收它们等。
Cognito - 联合用户
您的移动用户实际上是使用federated users 进行身份验证的。但是，其中一个联合用户频道恰好是认知频道。您可以添加更多，OpenAuth、Google、Facebook、SAML 等，在这里您可以添加客户端使用的身份验证类型。然后，用户将使用他们的用户名和密码向客户端安全提供程序进行身份验证，然后这些凭据通过联合用户传递到 API，因此必须设置联合用户以使用与您的客户端相同的身份验证机制。见下文blog post
对于这个解决方案，我们有多种选择。 1. 通过联合用户将用户凭据传递给 API，这假设用户界面调用 Web 服务，但正如您提到的那样，它是工作流，并且我假设用户不会像使用移动应用程序那样直接访问该服务。即服务被机器作为服务器上的后台进程调用。这意味着该解决方案将不起作用。选项 2. 是为客户端创建一个新用户。这与通过移动应用程序访问服务相同。为此，您需要在客户端上做一些额外的工作，因为您需要检索临时访问令牌。
建议的解决方案
创建 API 的第二个版本作为移动 API 的包装器或扩展，并使用上述 API 密钥。为什么？
编辑：我对解决方案 2 的建议不正确。 AWS 文档说following 要将 API 方法包含在使用计划中，您必须配置单个 API 方法以需要 API 密钥。对于用户身份验证和授权，请勿使用 API 密钥。使用 IAM 角色、Lambda 授权方或 Amazon Cognito 用户池。
AWS 还说以下内容可用于controlled access
并非所有上述方法都用于授权，例如 CORS 实际上保护用户免受跨站点脚本的影响，并且如所示 API 密钥仅用于使用计划。资源策略只是通过限制对 IP 地址的访问来进一步保护 API，因此您唯一的选择实际上是选项 1 中描述的 IAM 角色，以及选项 3 中描述的联合用户或您自己的自定义 lambda 授权，如果您使用的是 Lambda，或者如果您使用的不是用 API Gateway 包装的 lambda，则您自己的授权人。
【讨论】：
您可以单独使用 API 令牌进行授权（除非最近已将其删除） 我已经在多个应用程序中使用它们。 Authentication 不建议这样做——但如果它们足以进行授权，则它是特定于应用程序的 它们已通过更安全的方法进行了补充，但代价是客户端和服务器都非常复杂。
API 令牌的优点是发行者、客户端和服务器易于使用，因为它们不需要复杂的签名或协议——但它们的基本安全性不如它们可以重复使用并且通常不会很快过期。否则它们等同于不记名令牌。
安全性非常依赖于上下文——请考虑以下问题：
你到底在保护什么（提供安全for）？安全漏洞的风险和成本是什么？实施和使用它的成本/努力是多少？
许多安全“漏洞”并不在于身份验证协议处理本身，而是在于如何“开箱即用”管理数据——没有安全是完美的，这意味着追求完美安全的成本是无限的，但效率会降低。通常，建议平衡潜在损失的风险和成本与实施和维护成本。
您可以拥有一个“高度安全”的 API，但由于在通过受保护网关之前和之后的处理，也有很高的破坏和数据丢失风险。在许多合理的情况下，不是专注于用银行金库和装甲卡车保护“前门”，而是保护数据处理，以使具有重大安全风险的数据不会通过前门。
AWS 提供了一系列技术特性——但最终取决于每个客户是否实施适合其使用的技术特性。 API 密钥确实有一系列适当的用例，特别是在服务器到服务器的通信中，尤其是在不涉及个人身份（和 PI 数据）的情况下，或者 API 主要涉及服务而不是数据的情况下（例如，图像缩略图 API不存储状态并且不提供对数据的访问）。在使用 HTTPS/SSL 和可能的其他安全因素（例如帐户密码、IP 范围白名单和最少访问权限的一般策略）支持时。
不要低估“便签”因素。如果您让安全访问对您的用户来说太痛苦了，他们会找到一种方法来减轻痛苦，但安全性会比他们没有动机规避的更简单的措施更安全。
【讨论】：