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

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

Клиент должен пройти аутентификацию на конечной точке аутентификации по отдельному каналу, используя метод аутентификации, зарегистрированный для его <client_id> (метод, определенный в параметре <token_endpoint_auth_method> метаданных клиента). Методы аутентификации клиента регулируются требованиями обеспечения безопасности авторизации, применяемыми к серверу авторизации в зависимости от профиля безопасности OpenID API. При применении базового профиля безопасности допускается использование TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0: "tls_client_auth", "client_secret_jwt" или "private_key_jwt" (раздел 7 [6]). При применении расширенного профиля безопасности допускается использовать только "tls_client_auth" и "private_key_jwt" (раздел 7 [6]).

При использовании "tls_client_auth" необходимо руководствоваться требованиями, определенными в подразделе 7.4 [6].

При использовании механизмов аутентификации "client_secret_jwt" (подраздел 7.2 [6]) и "private_key_jwt" (подраздел 7.3 [6]) в параметре <client_assertion> в качестве параметра <aud> следует использовать идентификатор эмитента сервера авторизации (параметр метаданных сервера авторизации <issuer> (подраздел 5.4 [6]). Для обеспечения взаимодействия при запросе аутентификации сервер авторизации должен принимать данный идентификатор эмитента или URL конечной точки аутентификации по отдельному каналу в качестве значения, идентифицирующего его как целевую аудиторию <aud>.

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

- <scope>: (обязательный) область запроса; определяет перечень свойств защищаемых данных конечного пользователя, к которым запрошен доступ; параметр <scope> должен содержать значение "openid" (пункт 6.2.1 [6]). Параметр <scope> может содержать и другие значения, которые определяются на этапе разработки сервера авторизации исходя из его прикладных целей и задач;

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

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

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

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

- <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" (подраздел 7.2 [6]) и "private_key_jwt" (подраздел 7.3 [6]) используются дополнительные параметры <client_assertion> и <client_assertion_type>.

Ниже приведен пример запроса аутентификации:

Декодированный <login_hint_token>:

Декодированный JWT из параметра <client_assertion>: