将Cognito Protected AWSGateway API公开给客户

2 回答

• 0

  我想这将是服务或（服务器到服务器）通信服务，因为这个术语使用的是Oauth Standard是 client_credentials grant类型 .

  获取token获取令牌后，您需要传递此令牌 Authorization 或 API Gateway Custom Header for AWS Cognito .

  回复于 2024-05-10T07:45:47+08:00
• 0

  要正确回答您的问题，我们需要更多信息 .

  • 内部工作流程是否可以配置为使用REST服务？

  • 内部工作流程支持哪些身份验证过程？

  SDK or no SDK

  您可以通过生成的SDK或您自己的代码访问API Gateway中的Web服务 . 有关从API网关控制台生成SDK的说明，请参见here .

  通过身份验证调用Web服务可以通过IAM，API密钥，Cognito，自定义授权器四种方式完成 . 我要提到前三个 .

  IAM

  • 步骤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 Secret和Key SDK调用API .

  API Keys

  如果您向API添加密钥，则移动应用程序将失败，因为它没有这些密钥 . 最好部署可以包装现有API的不同版本的API，可以提供特定于工作流的附加功能 . 要了解如何执行此操作，请按照此link进行操作 .

  API密钥的优点是您可以限制对API网关功能的访问，随意删除密钥，回收它们等 .

  Cognito - Federated Users

  您的移动用户实际上正在使用federated users进行身份验证 . 但是，其中一个联合用户 Channels 恰好是认知的 . 您可以添加更多，OpenAuth，Google，Facebook，SAML等，在这里您可以添加客户端使用的身份验证类型 . 然后，用户将使用其用户名和密码对客户端安全提供程序进行身份验证，然后通过联合用户将这些凭据传递给API，因此必须将联合用户设置为使用与客户端相同的身份验证机制 . 请参阅以下blog post

  对于此解决方案，我们有多种选择 . 1.将用户凭据传递给具有联合用户的API，这假设用户界面调用Web服务，但正如您所提到的那样是工作流，并且我假设用户不像访问移动应用程序那样直接访问服务 . 即服务由机器调用作为服务器上的后台进程 . 这意味着此解决方案无效 . 选项2.是为客户创建一个新用户 . 这与通过移动应用程序访问服务相同 . 要做到这一点，需要在客户端上做一些额外的工作，因为您需要检索临时访问令牌 .

  • 步骤1.使用SDK，或者自己编写API接口 .

  • 步骤2.在Cognito中生成用户以供后端系统使用 .

  • 步骤3.使用cognito用户获取访问令牌

  • 步骤4.使用访问令牌访问API网关中的Web服务 .

  Suggested solution

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

  • 可以限制对API的访问

  • 不同的版本意味着您可以扩展它并添加特定于工作流的其他功能

  • 最容易实现，因为没有密钥交换，对请求标头的此类更新 .

  EDIT: 我对解决方案2的建议不正确 . AWS文档说following要在使用计划中包含API方法，您必须配置各个API方法以要求API密钥 . 对于用户身份验证和授权，请勿使用API密钥 . 使用IAM角色，Lambda授权程序或Amazon Cognito用户池 .

  AWS还说以下内容适用于controlled access

  • Resource policies 允许您创建基于资源的策略，以允许或拒绝从指定的源IP地址或VPC endpoints 访问您的API和方法 .

  • Standard AWS IAM 角色和策略提供灵活且强大的访问控制，可应用于整个API或个别方法 .

  • Cross-origin 资源共享（CORS）允许您控制API响应跨域资源请求的方式 .

  • Lambda authorizers 是Lambda函数，它们使用承载令牌身份验证以及标头，路径，查询字符串，阶段变量或上下文变量请求参数描述的信息来控制对API方法的访问 .

  • Amazon Cognito 用户池允许您创建可自定义的身份验证和授权解决方案 .

  • Client-side SSL 证书可用于验证对后端系统的HTTP请求是否来自API网关 .

  • Usage plans 允许您向客户提供API密钥 - 然后跟踪和限制每个API密钥的API阶段和方法的使用情况 .

  并非所有上述方法都用于授权，例如CORS实际上保护用户免受跨站点脚本的攻击，并且所看到的API密钥仅用于使用计划 . 资源策略通过限制对IP地址的访问来进一步保护API，因此您唯一的选择实际上是选项1中描述的IAM角色，以及选项3中描述的联合用户或您自己的自定义lambda授权，如果您使用的是Lambda，或者如果您使用的是除了使用API网关包装的lambda之外的其他内容，那么您自己的授权者

  回复于 2024-05-10T07:45:47+08:00