API Gateway: сочетание аутентифицированных и неаутентифицированных конечных точек - PullRequest
0 голосов
/ 20 апреля 2020

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

Вот упрощенная и приблизительная схема системы, о которой я думаю

Для моей системы я буду использовать Auth0, и я думаю, что я хочу, чтобы service проверял, действителен ли токен, используя ключ publi c вместо шлюз делает это. Это дает мне больше гибкости, если я хочу когда-нибудь опубликовать один из моих сервисов c. И я думаю, что я хочу, чтобы мой шлюз был маленьким.

Но как шлюз будет обрабатывать смесь аутентифицированных конечных точек, не прошедших проверку подлинности? IE Я хочу сделать конечную точку GET "открытой", а конечная точка POST требует входа в систему. Какой объект должен управлять, является ли конечная точка «открытой» или «требует входа в систему», шлюзом или службой?

  1. Должен ли я всегда иметь шлюз для передачи запроса в службу , независимо от того, вошел ли пользователь в систему или нет, и иметь службу вернуть 401?
  2. Или должен * шлюз содержать некоторые логи c о том, какие конечные точки требуют входа в систему, и вернуть 401, если в запросе нет токена? Пропуск услуги полностью.

1 Ответ

0 голосов
/ 06 мая 2020

Да, он настроен на шлюз, который вы будете использовать. Например, на AWS API-шлюзе у вас может быть лямбда-пользовательский авторизатор шлюза для точек доступа. Функция Authorizer может «авторизоваться», возвращая ok для всех запросов к этой конечной точке.

Подробнее здесь

...