OAuth для микросервисов с API Gateway - архитектура - PullRequest
Новая
       16

OAuth для микросервисов с API Gateway - архитектура

0 голосов
/ 07 мая 2018

В микросервисной архитектуре шлюз API находится перед API. Целью этого является, например, изменение некоторых параметров запроса / ответа для отдельной точки входа или проверки аутентификации и т. д. Теперь я хотел бы защитить свой API-интерфейс с помощью потоков OAuth2 для получения токена доступа. Проблема состоит в том, чтобы решить, кто является действительным клиентом OAuth, я продемонстрирую это на примере SPA:

a) Это SPA, который запустил запрос oauthorize (к шлюзу API) с использованием неявного предоставления. Затем шлюз Api просто перенаправит запрос на сервер авторизации OAuth, действуя как единая точка входа, с помощью / authorize из неявного потока

b) Является ли это самим API-шлюзом, то есть SPA отправляет имя пользователя и пароль конечного пользователя на API-шлюз (конечно, здесь SPA необходимо доверять учетным данным конечных пользователей), который затем воздействует на его владелец в качестве oauth-клиента с использованием пароля владельца ресурса

c) вообще отключить шлюз api и создать сервер авторизации oauth «параллельно» шлюзу api, что означает, что вы потеряете единственную точку входа и т. Д.

Следующая картинка демонстрирует очень абстрактную архитектуру, и вопрос о числовом значении "[2]", если этот запрос инициируется SPA и проходит через шлюз api, или если шлюз api перехватывает запрос и действует как отдельный клиент?

OAuth с API-шлюзом

Я предполагаю, что всегда следует использовать наиболее подходящий тип предоставления для конкретного клиента, независимо от того, находится ли шлюз API между ними или нет. Это будет означать, что когда дело доходит до OAuth, API-шлюз просто пропускает запрос авторизации клиента независимо от используемого им типа предоставления. Поэтому [2] на рисунке будет исходить от клиента, а не от шлюза API, действующего как клиент OAuth. Это правильно? Как уже упоминалось, это действительно сложно, когда дело доходит до приложений сторонних производителей, так как вы, вероятно, можете использовать грант с паролем, который имеет огромные недостатки, например. освежение невозможно для SPA.

1 Ответ

0 голосов
/ 07 мая 2018

Пожалуйста, имейте в виду, что это ответ, основанный исключительно на мнениях, потому что ваш вопрос довольно расплывчатый.

Мне не нравится идея использования API-шлюза в качестве точки, которая аутентифицирует запросы. Я думаю, что это противоречит принципу единой ответственности. Цель шлюзов обычно состоит в том, чтобы предоставить свой бэкэнд внешним клиентам, возможно, изменить контракт для некоторых конкретных клиентов и т. Д. Но это также не должно аутентифицировать вызовы. Кроме того, он должен был бы делать это на основе данных, передаваемых ему, которые вам все равно придется собирать где-то еще.

Другая вещь, которую я считаю нежелательной, заключается в том, что вы рассматриваете возможность использования пароля владельца ресурса для своего SPA. Это не правильный вариант использования для этого потока грантов. Вы можете посмотреть в этой статье, которая объясняет это гораздо лучше, чем я мог: https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications

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

Если вы используете шлюз API облака Spring (по сути, прокси-сервер zuul), вам нужно будет добавить правильную конфигурацию, чтобы он перенаправлял все заголовки и перенаправления безопасности. Этот пример работает для меня: 

server:
    use-forward-headers: true

zuul:
    addHostHeader: true
    routes:
        <your oauth server route>:
            url: <your oauth server url>
            path: <if youve got any prefix>
            sensitiveHeaders:
            stripPrefix: false
...