Возвращение API-шлюза 403 - запрещено

Question

У меня есть API-шлюз с конечной точкой, которая выполняется с помощью интеграции прокси-сервера AWS Lambda.Я также настроил собственный авторизатор для этой конечной точки.Я вижу проблему, когда первый запрос, который я делаю к этой конечной точке, был успешным, но дополнительные вызовы не будут выполнены;Я получаю 403 - Запрещенная ошибка.Если я подожду некоторое время, я могу сделать еще один запрос, который будет выполнен успешно, но затем я начну видеть ту же проблему.

Вот мой код для авторизатора:

const jwt = require('jsonwebtoken');

exports.authorizer = async function (event, context) {
  const bearerToken = event.authorizationToken.slice(7);
  const { payload } = jwt.decode(bearerToken);
  return {
    principalId: payload.sub,
    policyDocument: {
      Version: '2012-10-17',
      Statement: [{
        Action: 'execute-api:Invoke',
        Effect: 'Allow',
        Resource: event.methodArn,
      }],
    },
  };
};

В журналах шлюза API дляВ этой конечной точке я вижу, что авторизатор возвращает Allow, но я все еще вижу, что авторизация не удалась:

(50ac5f87-e152-4933-a797-63d84a528f61) Клиент не авторизован для выполненияэта операция.

Кто-нибудь знает, как или почему это может произойти?

Answer 1

Проблема, я думаю, в том, что ваш авторизатор отправляет обратно.В вашем документе политики вы можете видеть, что вы возвращаете Resource: event.methodArn.

Это обычно работает, если ваш авторизатор не кэширует ответ от вашего специального авторизатора (он включен по умолчанию).Проблема, с которой вы сталкиваетесь, возникает, когда вы делаете запрос API Gateway и возвращаете кешированный ответ авторизатора, который не соответствует запрошенному ARN текущего запроса. В этом посте объясняется, как работают авторизаторы Lambda, в том числе кэширование .

Чтобы убедиться в этом, перейдите в консоль AWS и отключите кэширование для своего пользовательского авторизатора;как только вы это сделаете, вы больше не будете испытывать эту проблему.

Так как вы можете исправить это в долгосрочной перспективе?Есть несколько вариантов:

Отключить кэширование : это самое простое решение.Недостатком является то, что вы теперь вызываете свой авторизатор с каждым запросом, который увеличивает задержку в вашем API.

Возвращает более широкую политику : это лучшее решение, но более сложное.Здесь есть несколько вариантов, вы можете вернуть несколько Allow политик в вашем ответе авторизатора, которые применяются к любой конечной точке, которая использует этот авторизатор.

Если вы посмотрите на формат запроса авторизатора вы увидите, что methodArn имеет следующий формат:

{
    "type":"TOKEN",
    "authorizationToken":"{caller-supplied-token}",
    "methodArn":"arn:aws:execute-api:{regionId}:{accountId}:{appId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]"
}

Таким образом, вы, вероятно, возвращаете что-то подобное для methodArn:

arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/GET/my-resource/e56bde3c-7c77-46c6-bdf0-ab4a8cb5f5ca

A более широкогоПолитика, которая будет применяться к любому ресурсу для этой конечной точки:

arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/GET/my-resource/*

Если у вас есть несколько конечных точек, которые используют один и тот же авторизатор, вы можете вернуть несколько политик:

{
  "principalId": "user",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": "arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/GET/my-resource/*"
      },
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": "arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/POST/my-resource"
      }
    ]
  }
}