向客户端公开Cognoto保护的AWSGateway API

为了正确回答您的问题,我们需要更多信息。

• 能否将内部工作流配置为使用REST服务?
• 内部工作流支持哪些身份验证过程?

可以找到从API网关控制台生成SDK的说明 here .

通过身份验证调用webservice可以通过四种方式完成:IAM、API密钥、Cognito、自定义授权程序。我要提到前三点。

• 步骤1,在IAM中创建具有访问密钥和密钥的用户。
• 第2步,是否设置了一个角色,无法使用IAM访问API。去 IAM ,选择角色,创建角色,并授予其对您的 API网关功能。看起来是这样的:

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 .

• 步骤3,使用AWS密钥调用API SDK .

API密钥

link .

Cognito联合用户

您的移动用户实际上正在使用 federated users . 然而,其中一个联邦用户通道恰好是cognito。您可以添加更多,OpenAuth、Google、Facebook、SAML等,在这里您可以添加客户端使用的身份验证类型。然后,用户将使用其用户名和密码向客户端安全提供者进行身份验证,然后通过联邦用户将这些凭据传递给API,因此必须将联邦用户设置为使用与客户端相同的身份验证机制。见下文 blog post

• 步骤1.使用SDK,或者自己编写API接口代码。
• 步骤2.在Cognito中生成一个供后端系统使用的用户。
• 步骤4.使用访问令牌访问API中的Web服务

建议的解决方案

创建API的第二个版本作为移动API的包装器或扩展,并如上所述使用API密钥。为什么?

1. 可以限制对API的访问
3. 最容易实现,因为没有密钥交换,这样的更新 请求头。

我对解决方案2的建议是不正确的。美国焊接学会的文件说 following 要在使用计划中包括API方法,必须将各个API方法配置为需要API密钥。对于用户身份验证和授权,不要使用API密钥。使用IAM角色、Lambda授权人或Amazon Cognito用户池。

AWS还表示,以下内容适用于 controlled access

• 允许您创建基于资源的策略,以允许或拒绝从指定的源IP访问API和方法 地址或VPC端点。
• 标准AWS IAM 角色和策略提供了灵活而健壮的访问控制,可以应用于整个API或单个API
• 交叉起源 资源共享(CORS)允许您控制API如何响应跨域资源请求。
• Lambda授权人 由标题、路径、查询字符串、阶段描述的信息 变量或上下文变量请求参数。
• 亚马逊干邑 用户池允许您创建可自定义的身份验证和授权解决方案。
• 客户端SSL 证书可用于验证对后端系统的HTTP请求是否来自API网关。
• 使用计划 允许您向客户提供API密钥,然后跟踪并限制每个API的API阶段和方法的使用 钥匙

并非上述所有方法都是用于授权的,例如CORS实际上保护用户不受跨站点脚本的影响,而且正如所见,API密钥仅用于使用计划。资源策略只是通过限制对IP地址的访问来进一步保护API,因此您唯一的选项实际上是选项1中所述的IAM角色,以及选项3中所述的联邦用户或您自己的自定义lambda授权(如果您使用lambda),或者您自己的授权人,如果您使用的不是用API网关包装的lambda。

我猜这将是服务到服务或(服务器到服务器)通信,因为所使用的术语是Oauth标准 client_credentials 赠款类型。

请参阅文档以获取更多信息 token Authorization API Gateway Custom Header for AWS Cognito .

我在多个应用程序中使用过它们。 不建议将其用于 认证

API令牌的优点是易于为发卡机构、客户机和服务器使用,因为它们不需要复杂的签名或协议——但它们的基本安全性不如可重用性,并且通常不会很快过期。否则,它们相当于不记名代币。

安全是非常依赖上下文的——考虑以下问题: 你到底在保护什么(提供安全性) 对于 ) ? 安全漏洞的风险和成本是多少?实施和使用它的成本/工作量是多少? 您可以拥有一个“高度安全”的API,但由于在通过受保护的网关之前和之后进行处理,您也有很高的违约风险和数据丢失风险。在许多合理的情况下,我们不需要将重点放在用银行保险库和装甲车保护“前门”上,而是要确保数据处理的安全性,确保不会有重大安全风险的数据通过前门。 AWS提供了一系列的技术特性,但最终取决于每个客户如何实现适合其使用的特性。API密钥确实有一系列适当的用例,特别是在服务器到服务器通信中,特别是在不涉及个人身份(和PI数据)的情况下,或者在API主要涉及服务而不是数据的情况下(例如,图像缩略图API不存储任何状态,也不提供对数据的访问)。当使用HTTPS/SSL以及可能的其他安全因素(如帐户密码短语、IP范围白名单和最少访问的一般策略)作为支持时。