AWS API Gateway 自定义 Authorizer 奇怪的显示错误答案

【问题标题】：AWS API Gateway custom Authorizer strange showing errorAWS API Gateway 自定义 Authorizer 奇怪的显示错误
【发布时间】：2018-05-14 13:30:46
【问题描述】：

这里是上下文：

我在 API 网关中设置了一个资源。 /用户/公司
此资源有 2 种方法。获取并发布。
我已为此资源配置了自定义授权方。

问题：

我可以通过发送正确的授权信息来调用GET方法，我得到了预期的结果。
我尝试发送 POST 请求，但收到以下错误：

{
  "message": "User is not authorized to access this resource"
}

如果我等待几分钟，然后调用 POST 方法，它会起作用。
如果在调用 POST 方法并得到结果后我调用 GET 方法，它会显示与上述相同的错误。

另外，我已经为授权者禁用了缓存。

什么可能导致了这个问题？

【问题讨论】：

您能否打印自定义授权器 (jwtRsaCustomAuthorizer) 中的输入，并检查成功和失败的 GET/POST 请求之间的输入是否不同。另外能否请您确认您的自定义授权方是否是无状态的（即，实现将一些值存储为运行时变量，而授权逻辑取决于这些运行时变量）？
感谢您提供的信息，在我的自定义授权器中，我生成了一个用于 POST 或 GET 的策略。当我首先调用它们中的任何一个时，都会生成策略并且由于某种原因它被缓存。重置需要几分钟，我可以调用另一种方法。尽管将缓存设置为禁用，但还是发生了这种情况。我尝试在每次调用资源时为整个 API 网关生成一个策略，这很好地解决了这个问题。
策略似乎已为令牌缓存。在测试期间，我通常为每个请求创建一个新令牌。
关闭缓存后是否重新部署了 API？
救命问题????????

标签： aws-api-gateway custom-authentication

【解决方案1】：

这可以通过 buggy 的回答中描述的两种方式解决：https://forum.serverless.com/t/rest-api-with-custom-authorizer-how-are-you-dealing-with-authorization-and-policy-cache/3310

短版：

将客户授权人的 TTL 设置为 0
将自定义授权方策略资源设置为“*”

我已经尝试了每个解决方案，他们都为我解决了“用户无权访问此资源”的问题。

【讨论】：

将 TTL 设置为 0 就可以了。如果有人使用 cf 或 sam，请使用模板中的 ReauthorizeEvery 属性。
这可以解决问题，但是如果想要缓存怎么办？

【解决方案2】：

如果您使用event.methodArn 作为生成策略的资源并在不同功能之间共享授权者，则会发生此错误，因为策略缓存的工作原理。对于提供的令牌，它会在整个 API 中缓存策略，对于同一 API 和阶段中的所有方法和资源（如果它们共享相同的授权者），它将是相同的缓存条目。

例如，当向GET /users 发出请求时，ARN 将如下所示：

arn:aws:execute-api:us-1:abc:123/prod/GET/users

对具有相同身份验证令牌的任何端点的下一次调用将使用缓存策略，该策略是在第一次调用 GET /users 时创建的。该缓存策略的问题在于它的资源只允许单个特定资源arn: ... /prod/GET/users，任何其他资源都将被拒绝。

根据您希望限制策略权限的程度，您可以在创建策略时提及所有可能的资源

{
  "principalId": "user",
  "policyDocument": {
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/POST/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/orders"
        ]
      }
    ],
    "Version": "2012-10-17"
  }
}

或使用wildcards

"Resource": "arn:aws:execute-api:us-1:abc:123/prod/*/v?/*"

甚至

"Resource": "*"

您可以将policy variables 用于一些高级模板。

也可以通过使用通配符允许所有内容然后在另一个策略声明中拒绝特定资源来使用黑名单方法。

来源：

【讨论】：

我认为这应该是最好的答案。将 TTL 设置为 0（禁用缓存）将在调用端点时调用授权方。这可能不是开发人员想要的。
OOOOMMMMGGGG...你是真正的救生员??非常感谢
这是一个很好的答案，因为它描述了实际问题。
同意上述观点：这个答案解释了问题是什么以及如何解决它。在不知道为什么的情况下关闭缓存似乎是错误的方法。

【解决方案3】：

在您的自定义策略构建代码使用中，节点 js 模块 aws-auth-policy 你可以使用的Nodejs部分，

AuthPolicy.prototype.allowAllMethods = function () {
  addMethod.call(this, "allow", "*", "*", null);
}

在代码中

const AuthPolicy = require('aws-auth-policy');
  const policy = new AuthPolicy(principalId, awsAccountId, apiOptions);
           // policy.allowMethod(method, resource);
            policy.allowAllMethods();
            const authResponse = policy.build();

【讨论】：

【解决方案4】：

我通过将AuthorizerResultTtlInSeconds 设置为0 来解决此问题。

原因是我使用了共享授权人。然而，授权者通过读取请求的事件上下文并授予 IAM 来调用特定的 lambda。

因为授权方是共享的，所以它正在缓存响应，该响应是特定 lambda 的 IAM，用于（在我的情况下）300 秒的 TTL。

因此，我可以在一分钟内调用一个 API，下一分钟就不行了。

将上面的值更改为 0 解决了这个问题。

【讨论】：

【解决方案5】：

我面临同样的“用户无权访问此资源”我的错误是我没有在我的 api 网关的授权者中提供 OAuth 范围

【讨论】：

【解决方案6】：

感谢@Orest 的回答！要在 Auth0 custom authorizer 中的策略资源上设置通配符，请转到 lib.js 第 57 行并更改：

.then((decoded)=> ({
        principalId: decoded.sub,
        policyDocument: getPolicyDocument('Allow', params.methodArn),
        context: { scope: decoded.scope }
    }));

通过

.then((decoded)=> ({
        principalId: decoded.sub,
        policyDocument: getPolicyDocument('Allow', "*"),
        context: { scope: decoded.scope }
    }));

希望对大家有所帮助……

【讨论】：