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

Режим доставки токена для клиента (Poll, Ping или Push) определяется при регистрации клиента (параметр метаданных <backchannel_token_delivery_mode>). Клиент может зарегистрировать только один метод доставки токена, а сервер авторизации возвращает клиенту результат аутентификации только через зарегистрированный режим.

6.5.1. Запрос токена

Если клиент зарегистрирован для использования режимов Poll или Ping, то клиент получает результат аутентификации из конечной точки токена после прохождения аутентификации.

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

Применимые методы аутентификации клиента на конечной точке токена определены в пункте 5.5.1 ФАПИ.СЕК.

Примечание. Подробная информация о параметрах запроса аутентификации клиента приведена в подразделе 5.5 ФАПИ.СЕК.

6.5.1.1. Особенности запроса токена в режиме Poll

Если клиент зарегистрирован для использования режима Poll, то он опрашивает конечную точку токена с интервалом, ограниченным сервером авторизации значением параметра ответа аутентификации <interval>. При этом сервер авторизации может осуществлять длительный опрос, когда сервер авторизации отвечает на запрос токена, только если результат аутентификации стал доступен или истекло время ожидания ответа. Для длительных опросов рекомендуется использовать интервал 30 секунд.

Примечание. Рекомендации по опросу приведены в подразделе 5.5 [RFC6202].

Клиенты должны быть готовы ждать ответа не менее 30 секунд при использовании режима Poll. Сервер авторизации должен ответить в течение не более 30 секунд, даже при использовании длительного опроса. Интервал опроса измеряется с момента отправки запроса Poll. Для осуществления длительного опроса сервер авторизации может отвечать медленнее, чем предусмотрено интервалом. Клиент не должен отправлять два перекрывающихся запроса с одним и тем же значением <auth_req_id> и ждать получения ответа на предыдущий запрос, прежде чем отправлять следующий запрос. В случае если ответ получен, а интервал прошел, клиент может немедленно отправить следующий запрос. Для управления данной ситуацией сервер авторизации возвращает HTTP "503" с заголовком "Retry-After".

Примечание. Подробная информация приведена в пункте 7.1.3 [RFC7231].

Примеры поведения клиента в зависимости от различных ответов сервера авторизации с учетом ожидания в течение пяти секунд:

- Длинный опрос. Клиент делает запрос токена, а сервер авторизации возвращает ошибку <authorization_pending> через 30 секунд. В этом случае клиент может сразу выполнить следующий запрос токена.

- Стандартный опрос. Клиент делает запрос токена, а сервер авторизации возвращает ошибку <authorization_pending> через две секунды. В этом случае клиент ждет три секунды, прежде чем сделать следующий запрос.

- Сервер авторизации реагирует медленнее 30 секунд. Клиент делает запрос токена, и сервер авторизации не возвращает ответ в течение 30 секунд. В этом случае клиент отменяет текущий запрос и выполняет новый.

6.5.1.2. Особенности запроса токена в режиме Ping

Если клиент зарегистрирован для использования режима Ping, то он получает на конечной точке уведомления клиента ответ с <auth_req_id>, проверенный по параметру <client_notification_token>, и вызывает конечную точку токена для получения результата аутентификации.

Примечание. Клиент, настроенный в режиме Ping, может также опросить конечную точку токена. Сервер авторизации должен обращаться с таким клиентом, как если бы он был зарегистрирован для использования режима Poll.

6.5.1.3. Параметры запроса токена

Клиент отправляет запрос HTTP POST на конечную точку токена в формате "application/x-www-form-urlencoded" со следующими параметрами:

- <grant_type>: (обязательный) - должен содержать значение "urn: openid: params: grant-type: ciba";

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

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

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

6.5.1.4. Успешный ответ токена

Примечание. При формировании успешного ответа необходимо руководствоваться общими требованиями, определенными в пункте 7.2.3 ФАПИ.СЕК.

После получения от клиента, проверки актуальности и авторизации запроса токена, а затем после аутентификации связанного с предоставленным <auth_req_id> конечного пользователя и авторизации им запроса сервер авторизации возвращает успешный ответ токена (подпункт 5.4.2.14 ФАПИ.СЕК).

После успешного обмена на токен доступа представленное значение <auth_req_id> становится неактуальным. Если конечный пользователь, связанный с предоставленным идентификатором <auth_req_id>, не был аутентифицирован, не авторизовал запрос или клиент использует неактуальный <auth_req_id>, сервер авторизации возвращает ответ об ошибке (раздел 6.6).

Пример успешного ответа токена

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

6.5.2. Обратный вызов в режиме Ping

Если клиент зарегистрирован в режиме Ping, сервер авторизации после успешной или неудачной аутентификации конечного пользователя отправляет запрос в конечную точку уведомления клиента. В этом режиме сервер авторизации указывает в заголовке авторизации полученное значение <client_notification_token> в качестве токена на предъявителя и <auth_req_id> в теле запроса в формате application/json.

6.5.2.1. Проверка обратного вызова в режиме Ping

Клиент проверяет, что полученный <client_notification_token>, используемый для аутентификации запроса как токен на предъявителя, действителен и связан с <auth_req_id>. Если токен на предъявителя недействителен, возвращается сообщение об ошибке "HTTP 401 Unauthorized response". Для действительных запросов к конечной точке уведомления клиента возвращается ответ HTTP "204 No Content". Сервер авторизации также должен принимать ответы HTTP "200 OK", а тело в ответе игнорировать. Клиент не должен возвращать код HTTP "3xx", а сервер авторизации - следовать за перенаправлениями.

Для действительных запросов клиент использует полученный <auth_req_id> для создания запроса на токен доступа к конечной точке токена с использованием типа гранта "urn: openid: params: grant-type: ciba".

Примечание. Обработка кодов ошибок HTTP в диапазонах 4xx и 5xx определена подразделами 5.5 и 5.6 спецификации протокола HTTP [RFC7231].

6.5.3.1. Успешный ответ токена

Примечание. При формировании успешного ответа токена в режиме Push необходимо руководствоваться общими требованиями, определенными в подпункте 5.4.2.14 ФАПИ.СЕК.

Если клиент зарегистрирован в режиме Push, а конечный пользователь прошел аутентификацию и авторизовал запрос, сервер авторизации передает для конечной точки уведомления клиента сообщение, включая в полезную нагрузку в формате "application/json": ID токен, токен доступа, (опционально) токен обновления и параметр <auth_req_id>.

Для привязки ID токена, токена доступа и <auth_req_id> сервер авторизации включает значение хэш-функции токена доступа и <auth_req_id> в токене идентификации, используя заявленные свойства <at_hash> и <urn: openid: params: jwt: claim: auth_req_id> соответственно. В случае отправки токена обновления значение его хэш-функции присутствует в токене идентификации в качестве заявленного свойства <urn: openid: params: jwt: claim: rt_hash>.

Значение параметра <at_hash> определяется в соответствии с требованиями подпункта 5.4.3.4 ФАПИ. СЕК, а значение параметра <urn: openid: params: jwt: claim: auth_req_id> аналогично <at_hash> с учетом использования <auth_req_id>. При этом применяется алгоритм хэширования, указанный в параметре <alg> JOSE заголовка ID токена. Этот же метод используется для вычисления хэш-значения токена обновления (параметр <urn: openid: params: jwt: claim: rt_hash> ID токена).

Примечание. Данное требование применимо только для режима Push.

Пример обратного вызова Push

6.5.3.2. Проверка ответа токена

Клиент проверяет, что полученный <client_notification_token>, используемый для аутентификации запроса как токен на предъявителя, действителен и связан со значением параметра <auth_req_id>. Если токен на предъявителя недействителен, возвращается сообщение об ошибке "HTTP 401 Unauthorized response". Клиент проверяет ID токен (параметр <id_token>).

Примечание. Подробное описание проверки ID токена приведено в подпункте 5.4.2.17 ФАПИ.СЕК.

Клиент проверяет соответствие значения заявленного свойства <urn: openid: params: jwt: claim: auth_req_id> в <id_token> значению параметра <auth_req_id> в запросе аутентификации.

Клиент проверяет полученный токен доступа с помощью значения <at_hash> из ID токена путем сравнения значения base64url-кодирования левой половины хэш-кода полученного значения <access_token> с полученным значением параметра <at_hash> и аналогичным образом токен обновления (при наличии параметра <refresh_token>), используя <urn: openid: params: jwt: claim: rt_hash> из ID токена.

Примечание. Проверка производится в соответствии с рекомендациями подпункта 5.4.3.5 ФАПИ.СЕК.

Для действительных запросов к конечной точке уведомления клиента возвращается HTTP "204 No Content". Сервер авторизации также должен принимать ответы HTTP "200 OK", а тело в ответе игнорировать. Клиент не должен возвращать код HTTP "3xx", а сервер авторизации - следовать за перенаправлениями.

Примечание. Обработка кодов ошибок HTTP в диапазонах 4xx и 5xx определена подразделами 5.5 и 5.6 спецификации протокола HTTP [RFC7231]

Пример декодированного ID токена