Перенаправление на провайдера OAuth2 авторизации/идентификации

Группа страниц '/oauth/…​' производит авторизацию по протоколам OAuth 2.0 и OpenId Connect 1.0 на внешнем сервере.

Процедура проходит в три этапа с помощью ответов 3хх с перенаправлением (см. /rest/v1/model/oauth/…​).

Использование внешней OAuth авторизации предполагает предварительную регистрацию системы на стороне сервиса авторизации с указанием SCOPE и REDIRECT_URI, и получением CLIENT_ID и CLIENT_SECRET.

Сервер авторизации указывается в коллекции 'oauth/Providers'.
Все включенные серверы авторизации перечисляются в форме логина корневого веб-приложения как альтернативные способы авторизации.

Каждый сервер авторизации предполагает связанный с ним домен системы, в который происходит авторизация.
В случае, если внешний сервер авторизации может предоставлять информацию о доменах коммуникационной платформы, то его также можно включить в SCOPE и распарсить из ответа внешнего сервера данных.
По умолчанию же подставляется домен, указанный в свойствах провайдера платформы внешней авторизации.
В любом случае конечное решение о домене принимается служебным сценарием авторизации по токену ('iam_token_svcscript_code').

С учетом того, что при регистрации системы на внешней платформе задается постоянный 'redirect_uri', лишь один сайт системы может обслуживать внешнюю авторизацию через этого провайдера.
Это требует: создания сущности провайдера на этом сайте и инициации внешней авторизации на этом же сайте.

Дополнительно: Инструкция по подключению нового провайдера OAuth-авторизации

Для всех запросов:
Тип домена: мастер

Инициирует процесс авторизации/идентификации с помощью OAuth 2.0 и OpenId Connect 1.0.

В URL указывается код провайдера авторизации, который зарегистрирован в системе в коллекции 'oauth/Providers' и включен (поле 'enabled').

В коллекции 'oauth/Requests' создается сущность запроса в состоянии 'initial' (поле 'status') и ожидает обратного перенаправления.

Перенаправляет клиента на сервер авторизации/идентификации.
URI сервера авторизации берется из поля 'uri_authorize' сущности провайдера и дополняется GET-параметрами, определенными протоколом OAuth 2.0 и заданными в свойствах провайдера.

Производит обработку обратного перенаправления с сервера авторизации после ее завершения.

Обнаруживает в коллекции 'oauth/Requests' сущность запроса в состоянии 'initial' (поле 'status'), используя для этого GET-параметр 'state', переданный внешним сервером авторизации без изменения.

Производит POST-запрос на внешний сервер авторизации в соответствии с протоколом OAuth 2.0, обменивая полученный в виде GET-параметра 'code' на 'access_token' для дальнейшего обращения к внешнему серверу данных.
URI сервиса обмена кода на токен берется из поля 'uri_token' сущности провайдера. Параметры включают полученный 'code' и указанные 'client_id', 'client_secret', 'redirect_uri' в сущности провайдера.

Если производится идентификация OpenId Connect 1.0, то в ответе сервера авторизации дополнительно присутствует информация об учетной записи во внешней системе в виде JWT значения GET-параметра 'id_token'.

Если производится авторизация OAuth2, то с помощью 'access_token' производится запрос к серверу данных (поле 'uri_info' в сущности провайдера).

Привязывает внешнюю учетную запись к пользователю системы, осуществляя авторизацию по токену.
Предполагается, что в мастер домене создан служебный сценарий авторизации по токену, и его код указан в настройках мастер-домена ('iam_token_svcscript_code').

Сценарий получает на вход токен, должен обнаружить в коллекции 'oauth/Requests' соответствующий авторизованный запрос ('status = "authorized"' ).
Из сущности запроса производит выемку логина, домена, имени, емайла, кода провайдера (поля 'login', 'domain', 'name', 'email', 'provider_key').
На основании этих и других сведений бизнес-логика сценария определяет локальную учетную запись пользователя и возможность прилинковать к ней внешнюю учетную запись. Сценарий возвращает в переменных 'result', 'domain', 'login'.
При необходимости сценарий может создать локальную учетную запись пользователя в соответствующем домене.

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

По результату успешной авторизации производится установка cookie и перенаправление на корневое веб-приложение, которое при наличии сессии сразу переходит к отображению доступных приложений.