OID C Spring boot Refre sh сценарий токена

Question

В настоящее время мы работаем над приложением, имеющим микросервисную архитектуру со следующими компонентами, как показано на изображении ниже, и все работает нормально. Однако необходимо кое-что прояснить по следующим пунктам.

1. Для защиты связи между шлюзом и Deep microservice мы передаем IDToken и проверяем его на каждом уровне микросервиса, однако, как только IDtoken истекает, сервис возвращает код состояния 401, а затем в Ui мы запускаем поток авторизации, который в конечном итоге приводит к полному обновлению страницы sh, и если пользователь в середине отправки очень большой После этого все данные будут потеряны в соответствии со спецификацией OID C, мы не можем обновить sh ID токен, поэтому не уверены, как справиться с этим сценарием.

2. Чтобы преодолеть первую проблему, мы могли бы передать access_token в microservice, а не в idtoken, однако нам нужно каждый раз вызывать /userinfo конечную точку для получения информации о пользователе от провайдера и учитывая высокий уровень параллелизма, является ли хорошей практикой продолжение работы?

3. Или мы что-то здесь упускаем, и есть лучшие альтернативы для решения этой проблемы?

Любая помощь будет высоко ценится

OID весенней загрузки C Свойства в файле application.yml

security:         
    oauth2:
      client:
        registration: 
          pingIdentity: 
            scope:
            - openid
            - profile
            - email
            - phone
            - job_title
            - scoped_entitlement
            - authorization_group
            - entitlement_group
            - organizational_data
            - basic_start_authorization            
            client-id: <Client  ID>
            client-secret:  <Client  Secret>
            provider: pingIdentity
        provider:
          pingIdentity: 
            issuer-uri: <Issuer URI>

Answer 1

Я думаю, что есть проблема концепции, использующей open id connect.

Open id connect не является протоколом аутентификации / авторизации, как oauth2, это слой поверх oauth2 для предоставления пользовательской информации клиенту.

Таким образом, предполагаемая аудитория для информации, содержащейся в idtoken - это приложение, которое пытается использовать ресурс (веб-интерфейс), а не сервер ресурсов (микросервис). Как вы можете видеть здесь

https://openid.net/specs/openid-connect-core-1_0.html

Токен, который необходимо отправить на микросервис, является токеном доступа, который выдается вместе с idtoken, потому что это токен, который должен использоваться для авторизации действия.

Другая проблема заключается в том, что вам может потребоваться информация о пользователе для выполнения какого-либо действия в службе, но это не является частью того же потока.

поток аутентификации / авторизации только гарантирует, что один пользователь является действительным и имеет привилегии для выполнения определенных действий на определенном сервере ресурсов (микросервис)

Если после этого, когда процесс аутентификации завершился, вам необходимо получить информацию о пользователе, я предлагаю у вас есть три возможных решения:

1. вы можете использовать токен jwt (токен доступа с самошифрованием) в качестве токена доступа вместо непрозрачного, чтобы вы могли получить идентификатор пользователя в подпретензии; при этом запросите службу пользователя, чтобы получить другую информацию.

2. Как и в первом пункте, вы можете использовать токен jwt acces и, кроме того, добавить пользовательские заявки для хранения дополнительной пользовательской информации

3. если вы выполняете проверку токена доступа в шлюзе zuul, вы можете получить информацию о пользователе в шлюзе и передать пользовательский jwt на микросервисы с помощью информация вам нужна Этот токен не обязательно должен быть токеном доступа, поскольку шлюз выполняет аутентификацию / авторизацию.

Таким образом, вы можете без проблем обновить sh свои токены доступа

Answer 2

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

Вы можете рассмотреть следующие варианты.

1. Сохраняйте повторяющуюся задачу в вашем SPA который будет проверять текущее время с истечением срока действия IDToken. Когда срок действия токена истекает (скажем, менее чем за 5 минут), SPA выдаст небольшой диалог и попросит пользователя ввести свои учетные данные. Как только форма отправлена, новый токен будет получен и заменен в сеансе / локальном хранилище или готовится ie.

   Таким образом, когда пользователь отправляет форму, она будет с новым токеном.

   Это не потребует никаких дополнительных услуг, чем текущие, и вам просто понадобятся дополнительные функции в SPA.

   Недостатком этого является то, что пользователь должен снова ввести пароль.

2. Если вы можете определить другой сервис для получения referh_token вместе с IDToken и сохранения его, тогда SPA может продолжать посылать запросы сердцебиения через регулярные интервалы. Запрос может быть отправлен, когда страница находится в фокусе пользователя / или пользователь взаимодействует со страницей локально. (например, можно отправлять каждые 5 минут при перемещении / прокрутке мыши и т. д. c.).

   Бэкэнд-сервис проверит, истекает ли срок действия токена, затем он использует токен refre sh, чтобы получить новый токен, а затем передаст его SPA. SPA обновит токен для последующих запросов в его конце. Все это будет происходить в фоновом режиме, не мешая пользователю, пока он работает на странице.

   Вам придется столкнуться с дополнительной сложностью в обмен на удобство пользователя.