Я пытаюсь создать следующие приложения:
- Внешний интерфейс: Angular 7.x (начальная загрузка и материал)
- Бэкенд: пружинные загрузочные (2.1.x) микросервисы(используя шлюз zuul в качестве основной точки входа в бэкэнд-сервисы)
Приложение переднего плана
В настоящее время имеется простой механизм аутентификации (нет интеграции oauth2 с другими провайдерамиреализовано еще).Однако токен авторизации генерируется и сохраняется в локальном состоянии.В конце концов, вы также захотите разрешить вход в систему oauth2.
Для каждого оставшегося вызова, выполняемого внутренним сервером, добавляется заголовок «Authorization: Bearer» (через перехватчик).
Back endapp
На сервере все запросы проходят через шлюз zuul.На шлюзе имеется фильтр, который проверяет токен, а затем генерирует другой «пользовательский» токен JWT, который используется вместо этого при переходе к микросервисам.Кроме того, микросервисы между ними используют этот «пользовательский» токен jwt для аутентификации запросов между собой.
OAuth2 Client Integration
В одном случае использования я хочу аутентифицированный пользователь для авторизации через oauth2 внутреннего приложения для вызова API-интерфейсов других поставщиков услуг.
Идея состоит в том, что все взаимодействие со службами другого провайдера будет осуществляться через внутреннее приложение:
- Пользователь выполняет действие в приложении переднего плана.
- Вызывается повторный вызов в приложение заднего плана (передан заголовок авторизации)
- Внутренний шлюз проверяет подлинность пользователя, а затем распространяется (спользовательский токен JET) запрос к соответствующему микросервису
- Микросервис, обрабатывает запрос и, в конечном итоге, может совершать вызовы или вызовы сторонних API с использованием предыдущей информации авторизации oauth2 (токен доступа / обновления) для текущего пользователя.
- Результат обрабатывается микросервисом, а затем отправляется обратно клиенту.
Таким образом, все звонки сторонним провайдерам будут передаваться через бэкэнд.
Проблема
В одной из микро-служб я попытался включить функциональность клиента oauth2 (через @ EnableOauth2Client), но когда приложение весенней загрузки перенаправляет на URL-адрес авторизации другого поставщика, в браузере возникает ошибка CORS.(Сгенерированный URL в порядке и работает, если открыт на странице браузера).Даже если это сработало, я все еще вижу проблему с URL-адресом обратного вызова, поскольку URL-адреса защищены в бэкэнд-приложении.(Необходимо получить обратный вызов, но также иметь возможность «определить», для какого пользователя предназначен обратный вызов, чтобы я мог сохранить токены доступа и обновить данные текущего пользователя)
Вопросы
Каков «правильный» или «передовой опыт» для предоставления такого типа функциональности?
Если «авторизация» выполняется в приложении переднего плана, нужно ли просто отправлять токены доступа / обновления для хранения в бэкэнде?Если да, то как реализовать «обратный вызов» в приложении переднего плана.