Обработка авторизации в загрузочном приложении OAuth 2.0 Spring при взаимодействии со сторонней службой
У меня есть опыт реализации различных сценариев OAuth 2.0 с участием как клиентов, так и серверов ресурсов, включая вызовы незащищенных служб моему клиенту и наоборот. Однако я столкнулся с ситуацией, которая немного озадачила меня в отношении процесса авторизации OAuth 2.0, особенно в отношении того, когда и где должно появляться приглашение на авторизацию.
Сценарий: У меня есть приложение Spring Boot, которое я буду называть Service1, настроенное с учетом клиентских зависимостей OAuth 2.0. Эта услуга включает форму входа, которая использует Google в качестве поставщика удостоверений. Моя цель — заставить Service1 отправить запрос другой службе, которую мы назовем Service2, которая не защищена с помощью OAuth 2.0. Я не уверен, как в этом случае должен проходить процесс авторизации и где должна происходить авторизация.
Ранее я успешно реализовал сценарий с участием двух служб Spring Boot: один действует как сервер ресурсов, а другой — как клиент OAuth 2.0. В этой настройке при попытке доступа к конечной точке, которая получает данные с сервера ресурсов, появляется окно авторизации. После входа данные успешно возвращаются.
Чего я хочу достичь: Я хочу повторить тот же процесс, что описан выше, но с некоторыми изменениями. Вот концептуальная диаграмма того, что я себе представляю:
Вместо использования конкретных «SnapStore» и «Службы печати», упомянутых на диаграмме, я намерен заменить их фиктивными службами в целях эксперимента. Мой основной вопрос вращается вокруг необходимости токенов доступа для связи между службами. В частности, когда я отправляю запрос от фиктивной службы, не поддерживающей OAuth 2.0, к защищенной службе OAuth 2.0, я получаю ответ 302 вместе со ссылкой для авторизации, которую затем перенаправляю.
Вопросы:
- Как следует обрабатывать поток авторизации OAuth 2.0 в этом сценарии, особенно учитывая взаимодействие с незащищенной сторонней службой (Service2)?
- Правильно ли я понимаю, что для связи между службами требуются токены доступа, и если да, то как следует должным образом управлять перенаправлением на ссылку авторизации в этом контексте?
Мы будем очень признательны за любые идеи или рекомендации о том, как правильно настроить и обрабатывать этот поток авторизации.
Ответы 1
В вашем сценарии Service1 действует как клиент OAuth 2.0, а Service2 — незащищенная служба. Когда Службе 1 требуется доступ к Службе 2, поток авторизации обычно зависит от требований Службы 2 и характера взаимодействия между службами.
Вот как можно обработать поток авторизации OAuth 2.0 в этом сценарии:
Взаимодействие с Сервисом2:
- Поскольку Service2 не защищен с помощью OAuth 2.0, для авторизации не требуются токены доступа. Таким образом, Службе 1 нет необходимости получать маркер доступа специально для связи со Службой 2.
Порядок авторизации:
- Когда Службе 1 требуется доступ к ресурсам Службы 2, она может отправлять HTTP-запросы непосредственно Службе 2 без использования авторизации OAuth 2.0. Служба 2 должна обрабатывать эти запросы на основе собственных механизмов аутентификации и авторизации.
Обработка запроса на авторизацию:
- Поскольку Service1 является клиентом OAuth 2.0, ему все равно может потребоваться запрашивать у пользователя авторизацию при доступе к защищенным ресурсам от имени пользователя. Однако если Служба1 просто отправляет внутренние запросы Службе2, не задействуя данные, специфичные для пользователя, запрос на авторизацию может не потребоваться.
Обработка перенаправлений:
- Если Служба 1 получает ответ 302 вместе со ссылкой авторизации при доступе к Службе 2, это означает, что Служба 2 требует некоторой формы аутентификации или авторизации. В этом случае вам необходимо соответствующим образом обработать перенаправление. Если Службе 2 требуется авторизация OAuth 2.0, Службе 1 может потребоваться перенаправить пользователя на сервер авторизации (например, Google), чтобы получить токен доступа перед доступом к Службе 2.
Связь между службами:
- Для связи между службами обычно требуется некоторая форма механизма аутентификации или авторизации. Однако это не обязательно должен быть OAuth 2.0. Если Service2 не требует авторизации OAuth 2.0, Service1 может напрямую взаимодействовать с Service2 без использования токенов доступа.
Таким образом, в сценариях, где Службе1 требуется доступ к незащищенной службе (Сервис2), вы можете обойти поток авторизации OAuth 2.0 и выполнить прямые HTTP-запросы. Однако если Service2 требует аутентификацию или авторизацию, вам необходимо обработать ее в соответствии с ее требованиями, что может включать в себя перенаправления и запросы на авторизацию пользователя.