Как API-шлюз проверяет токен доступа через самоанализ

Question

Я нашел одну интересную статью с такой иллюстрацией:

В нем говорится, что:

API Gateway проверяет токен доступа для всех входящих запросов через самоанализ

Но что это значит?

говорит, что шлюз идет на сервер авторизации и проверяет токен (JWT). зачем это нужно?

если у шлюза есть ключ publi c сервера авторизации, он может проверять действительность токена с помощью подписи, как и любая бэкэнд-служба, зачем нужен самоанализ и как это делается?

Answer 1

В зависимости от вашего провайдера идентификации это может быть сделано любым способом, но есть компромиссы.

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

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

Answer 2

Я полагаю, что вы просматриваете этот документ .

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

Самоанализ необходим для проверки информации токена на Сервере авторизации .
Это более безопасно, поскольку система может гарантировать, что полученный токен не является вредоносным, срок его действия истек и он получен из известного источника.
Подробная информация о том, как это делается, приведена в RF C 7662 .

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

Answer 3

API-шлюз в первую очередь предназначен для маршрутизации входящих вызовов в соответствующие кластеры MicroService.

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

Уровень проверки может зависеть от решения владельца продукта / архитектора. Это может быть так же просто, как проверка по списку в кешированном токене в памяти или углубленная проверка по набору заявок, проверке цифровой подписи, времени истечения, заявке аудитории и т. Д. c.

Вы можете просмотреть набор утверждения внутри токена с использованием JWT-декодера, такие как https://devtoolzone.com/decoder/jwt