6.3. "Стандарт Банка России "Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы. Обеспечение безопасности финансовых сервисов при инициации openid connect клиентом потока аутентификации по отдельному каналу. Требования" СТО БР ФАПИ.ПАОК-1.0-2021" (принят и введен в действие приказом Банка России от 23.07.2021 N ОД-1536)

Настоящий стандарт определяет конечную точку аутентификации по отдельному каналу, которая используется для инициирования аутентификации конечного пользователя непосредственно у сервера авторизации путем отправки в нее запроса аутентификации от клиента. Передача сообщений между клиентом и сервером авторизации на конечной точке аутентификации по отдельному каналу должна производиться по аутентифицированному TLS-соединению в соответствии с требованиями к протоколу TLS, определенными в пункте 5.8.3 ФАПИ.СЕК. Взаимодействие AD с сервером авторизации и CD с клиентом AD в процессе аутентификации должно осуществляться с использованием протокола TLS.

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>.

Пример запроса аутентификации

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

Декодированный JWT параметр "client_assertion"

6.3.1.1. Подписанный запрос аутентификации

Подписанный запрос аутентификации создается посредством кодирования всех параметров запроса аутентификации в виде заявленных свойств подписанного JWT (подраздел 5.7 ФАПИ.СЕК), с представлением каждого наименования параметра запроса в качестве имени заявленного свойства (claim), а его значения - в виде строки JSON. Подписанный запрос аутентификации передается в качестве параметра "request" запроса "HTTP POST".

Примечание. Как исключение, параметры <requested_expiry> могут быть представлены также числом JSON.

При этом к JWT предъявляются следующие требования:

1) должен содержать все параметры запроса аутентификации;

2) быть защищенным асимметричной подписью (подпункт 5.8.1.2 ФАПИ.СЕК);

3) содержать следующие зарегистрированные заявленные свойства (claims):

- <aud>: аудитория, значение идентификатора эмитента сервера авторизации, который идентифицирует сервер авторизации как предполагаемую аудиторию;

- <iss>: источник, должен содержать идентификатор клиента;

- <exp>: время ограничения срока действия подписанного запроса аутентификации;

- <iat>: время создания подписанного запроса аутентификации;

- <nbf>: время, до которого подписанный запрос аутентификации недопустим;

- <jti>: уникальный идентификатор подписанного запроса аутентификации.

Пример подписанного запроса аутентификации

Декодированный JWT параметра "request"

6.3.1.2. Код пользователя

Поток аутентификации по отдельному каналу в качестве механизма предотвращения создания нежелательных запросов аутентификации на AD конечного пользователя поддерживает использование параметра <user_code> - код пользователя, секрет конечного пользователя, известный серверу авторизации.

Примечание. Запрещено использовать в качестве <user_code> пароль учетной записи конечного пользователя, зарегистрированной у сервера авторизации.

При поддержке параметра <user_code> сервером авторизации клиент запрашивает у конечного пользователя значение кода пользователя для снятия риска создания запросов на аутентификацию для конечного пользователя третьими лицами, знающими <login_hint> или другие идентификаторы конечного пользователя. В случае использования нестатичных <login_hint> сервер авторизации может принимать запросы без <user_code>.

Сервер авторизации объявляет о поддержке кода пользователя значением параметра метаданных <backchannel_user_code_parameter_supported>. Параметр регистрации клиента <backchannel_user_code_parameter> указывает, поддерживает ли клиент параметр <user_code>.

Клиент запрашивает у конечного пользователя код пользователя для каждого потока аутентификации и не должен хранить его.

Механизм регистрации пользователем <user_code> на сервере авторизации выходит за рамки содержания настоящего стандарта. Сервер авторизации определяет механизм регистрации исходя из его прикладных целей и задач, а также должен предоставлять пользователю возможность изменения значения <user_code>.

6.3.2. Проверка запроса аутентификации

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

1. Аутентифицировать клиента зарегистрированным для него методом аутентификации (пункт 5.5.1 ФАПИ.СЕК).

2. Если запрос аутентификации подписан, проверить переданный параметром "request" JWT на корректность его структуры и подписи (подраздел 5.7 ФАПИ.СЕК).

3. Проверить наличие всех обязательных параметров в запросе аутентификации.

4. Проверить значения параметров. Если запрос содержит более одного или ни одного указания на пользователя (<login_hint_token>, <id_token_hint> или <login_hint>), сервер авторизации возвращает ответ об ошибке "invalid_request".

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

6. Если информация о пользователе недействительна или если сервер авторизации не может определить конечного пользователя, то клиенту возвращается ответ об ошибке.

Сервер авторизации должен игнорировать нераспознанные параметры запроса. При непрохождении проверки запроса аутентификации сервер авторизации возвращает ответ об ошибке (подраздел 6.8).

6.3.3. Успешное подтверждение запроса аутентификации

Если запрос аутентификации подтвержден, сервер авторизации вернет клиенту ответ HTTP "200 OK", содержащий следующие параметры:

- <auth_req_id>: (обязательный) уникальный идентификатор запроса аутентификации от клиента. Должен быть случайным и содержать достаточную энтропию (минимум 160 бит). Необходимо использовать символы "A" - "Z", "a" - "z", "0" - "9", ".", "-" и "_" для поддержки unpadded base64url. Значение идентификатора не должно указывать клиенту на связь с другими данными или иметь смысловую нагрузку.

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

- <interval>: (опциональный) JSON с положительным целочисленным значением, указывающим минимальное количество времени в секундах, которое клиент ожидает между запросами на опрос к конечной точке токена. Указывается, если клиент зарегистрирован для использования режимов Poll или Ping. Если значение не указано, клиент использует значения по умолчанию "5".

Пример ответа на запрос аутентификации

6.3.4. Проверка положительного ответа на запрос аутентификации

При получении в ответе аутентификации значения HTTP "200 OK" клиент проверяет наличие требуемых параметров и сохраняет значение <auth_req_id> для проверки обратных вызовов, полученных в режимах Ping и Push, или для запроса токена в режимах Poll и Ping, а также сохраняет значение <expires_in> для удаления запросов аутентификации, по которым не получены ответы в обратных вызовах Ping или Push.

6.3.5. Получение сервером авторизации согласия/авторизации конечного пользователя

После того как сервер авторизации проверил запрос аутентификации, он идентифицирует конечного пользователя, выбирает способ аутентификации и авторизации запроса в соответствии с запрашиваемым методом и инициирует интерактивную сессию с AD конечного пользователя (подпункт 5.4.2.7 ФАПИ.СЕК). Как только конечный пользователь аутентифицирован, сервер авторизации должен получить результат авторизации запроса о согласии передавать информацию клиенту (подпункт 5.4.2.8 ФАПИ.СЕК).