Шлюз API: сочетание аутентифицированных и неаутентифицированных конечных точек

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

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

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

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

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

person Ellie Maynard    schedule 19.04.2020    source источник


Ответы (2)


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

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

person Dawit    schedule 05.05.2020

На мой взгляд, это одна из основных обязанностей шлюзов API. Это может зависеть от конкретного шлюза API, но мы использовали одно изящное решение:

  • Все микросервисы определяют свои конечные точки и определяют, защищены они или нет, в файле дескриптора.
  • Когда он развернут (возможно, в CI), он регистрирует эти определения в шлюзе API.
  • Шлюз API принимает запрос и проверяет, защищен он или нет.
  • Шлюз API может дополнить запрос информацией о пользователе, если он защищен
  • Все запросы за пределами шлюза принимаются в безопасном режиме для принятия службами.

Таким образом, мы отделяем проблему аутентификации от бизнес-логики/функций.

person ismet özöztürk    schedule 21.05.2020