Мы рассчитываем предоставить сервер ресурсов клиентскому веб-клиенту, который авторизует соединения с использованием oAuth 2.0.
В идеале мы будем использовать поток кода авторизации для предоставления доступа отдельным пользовательским агентам пользователей,но похоже, что у клиента в настоящее время нет средств для использования полномочий SSO для проверки своих пользователей, вместо этого он использует собственную систему управления доступом пользователей, детали которой мы не знаем.
Возможный обходной путьбыло бы предложить пользователю использовать свои внутренние серверы аутентификации для получения токенов доступа и сделать их доступными для пользователей, как показано на приведенной ниже схеме через поток учетных данных клиента.Строго говоря, токены будут принадлежать клиентскому внутреннему серверу, а не агенту пользователя (браузеру), но на практике это не станет для нас проблемой, поскольку мы не планируем использовать токены ID на стороне клиента или связывать какие-либо метаданные вТокен доступа.Также этим токенам будут предоставлены очень короткие жизненные периоды.
Обратите внимание, что мы не хотим избегать аутентификации агента пользователя в нашей системе, вместо этого полагаясь надоверяя аутентификации, ранее выполненной клиентским бэкэндом.Вот почему мы не рассматриваем использование неявных потоков или потоков кода авторизации.
Мой вопрос заключается в том, существует ли подобная формализованная версия этого потока в какой-либо спецификации oAuth или OpenID Connect, или что-то в этом духе, которое могло бы отвечатьнаши требования?
Подводя итог, мы ищем поток, в котором сервер не oAuth проверяет пользователя на удаленном агенте пользователя и запрашивает токен доступа на его имя.
Заранее спасибо