Токены доступа и API Gateway: как обеспечить безопасность запросов

[@AntonLarinLive]

Не приведёт ли целевая схема с обменом токенов к перегрузке Authorization Server и проседанию латентности API Gateway? Ведь если на каждый ресурс нужен JWT со своими aud и scope, то это приведёт к постоянному запросу новых токенов (читай - потоку операций генерации электронной подписи, которая, обычно значительно медленней проверки), да ещё и валидации JWT как на API Gateway, так и дальше на сервисах? Да, есть кэширование, но оно эффективно для одного Resource, а когда клиент последовательно ходит к разным, то кэширование как бы и не очень поможет.

[@anador]

Да, это справедливое высказывание. Часто мы вынуждены находить компромисс с точки зрения НФТ между безопасностью и иными требованиями, например, к производительности. Поэтому и пишу, что подходы существуют разные, все со своими особенностями. Но если требования к ИБ в конкретном случае играют бОльшую роль, то подобные практики уместны, ну или по крайней мере полезно их держать в уме при проектировании.

Влияние на latency и на нагрузку на authorization server имеется, безусловно, и я это старался подчеркнуть. Однако, каким оно будет - зависит от различных факторов. В том числе и от того, с чем мы сравниваем. Здесь не зря рассмотрел такой механизм именно на примере схемы, когда мы уже ходим с API Gateway в authorization server, расширяя назначения такого "похода за обменом токенов".
Да, можно сказать, что кто-то кэширует у себя на стороне authorization server созданные JWT, а здесь нужно будет создавать новые, но это уже частный случай, как думаю.

Более того, для отдельных групп API или клиентов можно принять быстродействие важнее безопасности, и использовать для них отличный подход.

потоку операций генерации электронной подписи, которая, обычно значительно медленней проверки

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

[@AntonLarinLive]

Согласен, что идеального решения нет, всегда надо прикидывать и взвешивать плюсы и минусы в каждом конкретном случае. Но всё равно ваша статья подкинула хороших дров в мою личную топку размышлений про защиту API.

[@anisimovih]

Соответственно, с данным токеном, кроме сервиса, для которого запрос был предназначен, будет все еще возможно обращение в другие. И команды, разрабатывающие сервисы, к сожалению, обязательно попытаются так и сделать, пусть даже с благими намерениями.

То есть мы усложняем и замедляем систему вместо простого правила "отправлять/принимать внутренние запросы только через гейтвей*?

Снаружи» у client все равно будет существовать некий «general‑purpose session ID».

А в финальном решении он куда-то исчез?

[@anador]

То есть мы усложняем и замедляем систему вместо простого правила "отправлять/принимать внутренние запросы только через гейтвей*?

Здесь не могу согласиться, что это "простое" правило. Использование API Gateway для east-west трафика, то есть межсервисных запросов, возможно, но всегда оправдано и применимо. К тому же существуют разные подходы к разработке и нарезанию API: например, иногда одни и те же API могут использоваться как для внешних запросов, так и для внутренних (сейчас не говорю, плохо это или хорошо, но сам факт). Поэтому да, если есть возможность добавить дополнительные ограничения, это может работать, но здесь старался рассмотреть вопрос на более низком уровне с точки зрения наделения учетных данных, которые нужны для выполнения операции, минимальным набором необходимых полномочий.

А в финальном решении он куда-то исчез?

Нет, все верно, суть не меняется. Здесь имел в виду, что принципиально добавление еще одного уровня абстракции не решает всех проблем.