6.3.1. Запрос аутентификации

Запрос аутентификации по отдельному каналу выполняется напрямую от клиента к серверу авторизации, без прохождения через браузер конечного пользователя. Клиент должен послать запрос аутентификации к серверу авторизации, создав запрос "HTTP POST", который предоставит всю необходимую информацию для аутентификации конечного пользователя без запроса его идентификационных данных.

Клиент аутентифицируется в конечной точке аутентификации по отдельному каналу зарегистрированным у сервера авторизации для его <client_id> методом, определенным в параметре <token_endpoint_auth_method> его метаданных. Методы аутентификации клиента регулируются требованиями обеспечения безопасности авторизации, применяемыми к серверу авторизации в зависимости от применяемого профиля безопасности OPENID API. При применении профиля безопасности для доступа к сервисам в режиме только для чтения допускается использование TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0, <client_secret_jwt> или <private_key_WT> (подпункт 6.2.2.4 ФАПИ.СЕК). При применении профиля безопасности для доступа к сервисам в режиме чтения и записи допускается использование только TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0 и <private_key_jwt> (подпункт 7.2.2.12 ФАПИ.СЕК).

При использовании TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0 необходимо руководствоваться требованиями, определенными в пунктах 5.5.4 или 5.5.5 ФАПИ.СЕК.

При использовании механизмов аутентификации "client_secret_jwt" (пункт 5.5.2 ФАПИ.СЕК) и "private_key_jwt" (пункт 5.5.3 ФАПИ.СЕК) в параметре <client_assertion> в качестве заявленного значения аудитории (<aud>) следует использовать идентификатор эмитента сервера авторизации (параметр метаданных сервера авторизации <issuer> (подпункт 5.4.4.3 ФАПИ.СЕК)). Для обеспечения взаимодействия при запросе аутентификации сервер авторизации должен принимать данный идентификатор эмитента или URL конечной точки аутентификации по отдельному каналу в качестве значения, идентифицирующего его как целевую аудиторию (<aud>).

В состав запроса аутентификации клиент может включать следующие параметры:

- <scope>: (обязательный) область действия, определяет свойства защищаемых данных конечного пользователя, к которым запрошен доступ. В случае использования протокола OpenID Connect параметр <scope> должен содержать строку "openid"; (подпункт 5.4.2.2 ФАПИ.СЕК). Параметр <scope> может содержать и другие значения, которые определяются на этапе разработки сервера авторизации исходя из его прикладных целей и задач.

Примечание. Дополнительные сведения об использовании параметра <scope> приведены в разделе 3.3 [RFC6749].

- <client_notification_token>: (обязательный, если клиент зарегистрирован для использования режимов Ping или Push) предоставляемый клиентом токен на предъявителя, который будет использоваться сервером авторизации для аутентификации выполняемого клиентом запроса обратного вызова. Длина токена не должна превышать 1024 символов, и он должен соответствовать синтаксису токена на предъявителя.

Примечание. Дополнительные сведения приведены в разделе 2.1 [RFC6750].

- <acr_values>: (опциональный) запрошенные значения класса контекста аутентификации. Разделенная пробелами строка, определяющая идентификаторы классов контекста аутентификации, отображаемые в порядке предпочтения, которые сервер авторизации запрашивает для обработки запроса аутентификации ([OpenID. Core] подпункт 5.5.1.1). Средства аутентификации конечного пользователя имплементируются сервером авторизации, и требуемый класс контекста аутентификации возвращается в качестве заявленного свойства <acr> ID токена. При наличии параметра <acr_values> в запросе аутентификации полученный ID токен должен содержать значение заявленного свойства <acr>.

Примечание. Используемые значения идентификаторов <acr> определяются участниками взаимодействия, использующими данное заявленное свойство и должны однозначно определять методы и факторы аутентификации [ГОСТ Р 58833-2020].

- <login_hint_token>: (опциональный) информация в виде токена, идентифицирующая конечного пользователя, для которого запрашивается аутентификация. Механизм формирования данного параметра определяется на этапе разработки сервера авторизации исходя из его прикладных целей и задач.

- <id_token_hint>: (опциональный) информация о пользователе в виде ID токена, ранее выданного клиенту сервером авторизации, в качестве рекомендации идентификации конечного пользователя.

- <login_hint>: (опциональный) информация о пользователе для сервера авторизации относительно конечного пользователя, для которого запрашивается аутентификация. Значение содержит идентификационные данные конечного пользователя, по которым сервер авторизации может однозначно его идентифицировать (адрес электронной почты, номер телефона, идентификатор субъекта), и может быть предварительно получено от конечного пользователя клиентом. Механизм формирования данного параметра определяется на этапе разработки сервера авторизации исходя из его прикладных целей и задач.

- <binding_message>: (опциональный) идентификатор или сообщение, предназначенные для отображения как на CD, так и на AD, чтобы связать их вместе для транзакции посредством визуальной информации для конечного пользователя. Это связывающее сообщение позволяет конечному пользователю убедиться, что действие, предпринятое на AD, связано с запросом, инициированным CD (например, код подтверждения транзакции). Поскольку различные устройства могут иметь ограниченные возможности отображения и сообщение предназначено для визуального просмотра конечным пользователем, значение <binding_message> должно включать не более 100 символов и использовать ограниченный набор символов в виде простого текста: алфавитно-цифровые символы "А - Я", "а - я", "A - Z", "a - z" и "0 - 9" и знаки "_", "!". Если предоставленное значение <binding_message> является неприемлемым, клиенту возвращается ошибка "invalid_binding_message".

- <user_code>: (опциональный) секретный код, известный только пользователю, но проверяемый сервером авторизации. Код используется для авторизации процесса отправки запроса аутентификации на AD пользователя. Этот параметр присутствует, если значение параметра метаданных клиента <backchannel_user_code_parameter> соответствует поддержке кода пользователя (имеет значение "true").

- <requested_expiry>: (опциональный) значение времени жизни для запроса аутентификации - положительное целое число, позволяющее ограничивать по времени и корректного завершать сессии аутентификации.

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

Поскольку в потоке аутентификации по отдельному каналу сервер авторизации не взаимодействует с конечным пользователем через CD, клиент должен указывать один из параметров, содержащих информацию о пользователе: <login_hint_token>, <id_token_hint> или <login_hint>.

Запрос аутентификации выполняется с использованием метода HTTP POST в формате "application/x-www-form-urlencoded" и кодировкой символов UTF-8 в теле объекта HTTP-запроса.

В случае аутентификации применения механизмов аутентификации "client_secret_jwt" (пункт 5.5.2 ФАПИ.СЕК) и "private_key_jw" (пункт 5.5.3 ФАПИ.СЕК) используются дополнительные параметры <client_assertion> и <client_assertion_type>.