Авторизация шлюза API и выход из системы (соображения производительности / безопасности)

For security, I should not enable authorizer caching

Если у вас есть строгие требования к безопасности (например, как только токен становится недействительным, все запросы должны завершаться ошибкой), вам будет необходимо отключить кеширование авторизатора. См. Ответ от https://forums.aws.amazon.com/thread.jspa?messageID=703917:

Currently there is only one TTL for the authorizer cache, so in the scenario you presented API Gateway will continue to return the same cached policy (generating a 200) for the cache TTL regardless of whether the token may be expired or not. You can tune your cache TTL down to level you feel comfortable with, but this is set at level of the authorizer, not on a per token basis.

We are already considering updates to the custom authorizer features and will definitely consider your feedback and use case as we iterate on the feature.

It also means all authenticated APIs will have a go through one overhead of a Lambda authorizer...

Это так. Однако на практике моя команда боролась с холодным запуском Lambda и подключением ENI гораздо усерднее, чем с чем-либо еще, с точки зрения производительности, поэтому накладные расходы, добавленные нашим авторизатором, оказались незначительными. Это не означает, что снижение производительности нельзя было измерить, но это привело к увеличению задержки на порядок миллисекунд по сравнению с размещением кода авторизации непосредственно в Lambda, что имело смысл в нашем приложении. Напротив, холодный запуск Lambda часто может длиться до 30 секунд.

Also from a coding perspective, is it really a good idea to use authorizers which are hard to test end to end?

Во многих приложениях, построенных на сервис-ориентированной архитектуре, у вас будут «сквозные» сценарии, которые пересекаются с несколькими базами кода и могут быть протестированы только в развернутой среде. Очевидно, что тесты на этом уровне дороги, поэтому вам следует избегать функциональных возможностей тестирования, которые могут быть покрыты тестами более низкого уровня (модульными, интеграционными и т. д.). Тем не менее, по-прежнему чрезвычайно важно проверить связность вашего приложения, и тот факт, что вам понадобятся такие тесты, не обязательно является серьезным противником для SOA.

I could test the Lambda function as a unit. But what's more important to me is they are attached to the correct APIs. There's currently no way I see that allows me to test this easily.

Если вы рассматриваете возможность использования нескольких авторизаторов, один из способов проверить, правильно ли подключены авторизаторы, - это передать каждому авторизатору отпечаток пальца на конечную точку. Затем вы можете проверить связь с конечными точками, чтобы они вернули статус проверки работоспособности.

Например,

[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
                                       Payload:                            Payload:
                                       user identity                       status: ok
                                       authorizer: 1                       authorizer: 1

На практике у моей команды был один авторизатор для каждой службы, что делало тестирование этой конфигурации некритичным (нам нужно было только убедиться, что конечные точки, которые должны были быть защищены, были).

Another problem is. looking at the code, I can no longer tell what authorization is required easily... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the Lambda code itself.

Да, это правда, и природа сильно изолированной среды, которую было трудно протестировать локально, была одной из самых больших проблем, с которыми моя команда столкнулась при работе с инфраструктурой AWS. Однако я считаю, что при работе с пространством AWS это в основном кривая обучения. Сообщество разработчиков в целом все еще относительно плохо знакомо с множеством концепций, которые предоставляет AWS, таких как инфраструктура в виде кода или микросервисов, поэтому наши инструменты и обучение в этой области отсутствуют по сравнению с традиционной монолитной разработкой.

Подходит ли это решение для вашего приложения? Я не мог бы сказать этого без глубокого анализа. В более широком сообществе существует множество мнений, которые идут в обе стороны, но я хотел бы указать вам на эту статью, особенно на перечисленные заблуждения: Микросервисы - пожалуйста, не делайте этого. Используйте микросервисы, потому что вы разработали для них надежный вариант использования, а не только потому, что они являются новейшим модным словом в компьютерных науках.

Is there a good thing from using Authorizers? Or what's the best practice with this actually?

Моя команда использовала авторизаторы для AuthN (через настраиваемую службу проверки подлинности) и обрабатывала AuthZ на отдельном уровне Lambda (через другую настраиваемую службу проверки подлинности). Это было чрезвычайно полезно для нашей архитектуры, поскольку позволяло изолировать то, что часто было чрезвычайно сложными правилами безопасности для конкретных объектов, от простого вопроса идентификации. Ваш вариант использования может быть другим, и я, конечно, не буду утверждать, что знаком с лучшими практиками. Однако я укажу вам на Примеры авторизатора шлюза API для получения дополнительных идей о том, как вы можете интегрировать этот сервис в свое приложение.

Удачи.