Demo: Динамическая регистрация

Дисклеймер

Данный прототип НЕ является официальной разработкой и предназначен исключительно для ознакомительных целей.
Это возможный вариант реализации динамической регистрации клиентов.

Прототип разработан на основе официальных документов:

СТО БР ФАПИ.СЕК-1.6-2024: раздел 5.4.4 "Регистрация сервера авторизации (Discovery) и динамическая регистрация клиента"
cbr.ru/Crosscut/LawActs/File/9908
API е-Каталога Среды открытых программных интерфейсов (версия 1-b.2.1)
api.openbankingrussia.ru/obru-directory-v1.0.1

1. Discovery и получение метаданных сервера авторизации

Выбор сегмента API

Выберите тип клиентов для определения правильного сервера авторизации

Endpoint Discovery

URL автоматически подставляется и фиксируется в зависимости от выбранного сегмента API
(Минимальный набор: registration_endpoint, authorization_endpoint, token_endpoint, scopes_supported, grant_types_supported)

1.5. Получение Initial Access Token (IAT)

📋 Согласно obru-dcr-v1.1.1:
Initial Access Token (IAT) необходим для аутентификации запроса при динамической регистрации клиента (DCR). Получение выполняется через tls_client_auth с использованием клиентского сертификата ГОСТ.

Метод получения IAT

IAT используется если выдача токенов контролируется через сервисы Оператора среды.

Software ID (client_id)

Уникальный идентификатор ПО, зарегистрированного у Оператора.

Organization ID

Идентификатор организации (используется как aud в IAT).

HTTP-запрос на получение IAT (согласно спецификации)

POST /token HTTP/1.1
Host: auth.operator.example.com
Content-Type: application/x-www-form-urlencoded

client_id=<software_id>
grant_type=client_credentials
token_endpoint_auth_method=tls_client_auth

Проверки на стороне Сервера авторизации:

TLS сертификат должен быть действительным
CN сертификата должен совпадать с org_id организации
client_id (software_id) должен принадлежать организации

2. Регистрация клиента в Open API (СТО БР ФАПИ.СЕК-1.6-2024)

Прогресс заполнения

Название клиента (client_name)

Имя организации/ПО. Например: "ООО Современный потребитель", "Мобильный банк 2025".

Домашняя страница (client_uri)

Публичная страница приложения.

Redirect URIs

Список callback-URL для авторизации, минимум один необходим (например, https://you-app.ru/oauth/callback).

Контакты (contacts)

Ответственные за интеграцию.

Логотип (logo_uri)

URL логотипа (PNG/JPG/SVG).

JWKS URI (jwks_uri)

URL JWKS (актуально для private_key_jwt).

JWKS (jwks)

Объект JWKS, содержащий ключи, зарегистрированные данным Клиентом и передаваемые "по значению" в запросе Клиента.

Scopes (scope)

Что означают выбранные Scopes?

openid	Обязательный scope для OpenID Connect аутентификации
profile	Доступ к профилю пользователя: имя, фамилия и базовая информация
email	Получение email адреса пользователя
offline_access	Получение refresh_token для длительного доступа без повторной авторизации
accounts	Российский scope: Доступ к информации о банковских счетах и балансах
payments	Российский scope: Инициирование платежей и переводов
fundsconfirmation	Российский scope: Подтверждение наличия средств на счете

Grant Types

Подробнее о вариантах Grant Types

authorization_code	Классический поток для web-приложений с участием пользователя и redirect URI (самый безопасный способ получения токенов).
refresh_token	Позволяет получать новые access_token без повторного входа пользователя. Используется для автоматических обновлений сессии.
client_credentials	Поток для получения токенов без пользователя, только по client_id/client_secret (например, B2B или внутренние сервисы).

Метод аутентификации клиента (token_endpoint_auth_method)

✅ Используются одновременно оба метода:
• private_key_jwt - основной метод аутентификации через подписанный JWT
• tls_client_auth - дополнительная защита через взаимную TLS аутентификацию

Описание методов аутентификации

private_key_jwt	Рекомендуемый метод для ФАПИ: Аутентификация через подписание JWT приватным ключом клиента с использованием ГОСТ алгоритмов. Требует публикации JWKS с российскими криптографическими ключами.
tls_client_auth	Альтернативный метод: Взаимная TLS аутентификация (mTLS) с использованием российских сертификатов. Клиент должен иметь действующий сертификат от российского УЦ.

Настройки private_key_jwt

Алгоритм подписи (token_endpoint_auth_signing_alg)

Алгоритм для подписания JWT токенов. Для российских банков рекомендуются алгоритмы ГОСТ.

Российские алгоритмы ГОСТ для JWT:

GOST341012 - Цифровая подпись по ГОСТ Р 34.10-2012 (универсальный)
GOST341012_256 - 256-битная подпись на эллиптических кривых
GOST341012_512 - 512-битная подпись на эллиптических кривых
GOST341112_256 - HMAC с хэш-функцией ГОСТ Р 34.11-2012 (256 бит)
GOST341112_512 - HMAC с хэш-функцией ГОСТ Р 34.11-2012 (512 бит)

Требования для private_key_jwt:

Обязательное поле jwks_uri (указано выше)
Приватный ключ для подписания JWT
Публичный ключ в JWKS по указанному URI
Поддержка российских алгоритмов ГОСТ
Соответствие стандарту СТО БР ФАПИ.СЕК-1.6-2024

Настройки mTLS (tls_client_auth)

Привязка токенов к сертификату

Certificate-Bound Access Tokens (RFC 8705)
true - токен можно использовать ТОЛЬКО с тем же сертификатом, с которым он был получен. Даже если токен перехватят, он бесполезен без приватного ключа сертификата.
false - обычный bearer token, можно использовать с любого клиента.

Информация о клиентском сертификате

⚠️ НЕ обязательно прикреплять сам сертификат!
Обычно достаточно метаданных: Subject DN, Serial Number или Thumbprint. Полный сертификат нужен только если банк требует его для предварительной валидации.

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

Параметр сертификата, по которому банк будет идентифицировать клиента при mTLS аутентификации.

Требования для tls_client_auth:

Сертификат выдан российским удостоверяющим центром
Использование алгоритмов ГОСТ для криптографии
Регистрация сертификата в каталоге участников
Поддержка привязки токенов к сертификату (Certificate-Bound Access Tokens)
Указание параметра для идентификации клиента

Software ID (software_id)

Software Version (software_version)

Версия приложения (например "1.0.0").

После регистрации скопируйте client_id. Это ваши ключевые сведения для OpenAPI-интеграции.

3. Сертификаты для ГОСТ криптографии

📋 Сертификаты для установки ГОСТ каналов:
Для работы с российскими алгоритмами ГОСТ необходимы сертификаты от аккредитованных удостоверяющих центров.

Корневой сертификат УЦ ГОСТ

Корневой сертификат аккредитованного российского удостоверяющего центра для проверки цепочки доверия.

Клиентский сертификат ГОСТ

Сертификат клиента с ключевой парой ГОСТ для аутентификации и подписания.

TLS сертификат ГОСТ

Сертификат для установления защищенного ГОСТ TLS соединения с банком.

Цепочка сертификатов

Полная цепочка сертификатов от клиентского до корневого УЦ для валидации.

⚠️ Требования к сертификатам ГОСТ:

Сертификаты должны быть выданы аккредитованным российским УЦ
Использование алгоритмов ГОСТ Р 34.10-2012 для ключевых пар
Хэширование по ГОСТ Р 34.11-2012 (Стрибог)
Соответствие требованиям ФЗ-63 "Об электронной подписи"
Регистрация в реестре доверенных сертификатов Минцифры
Поддержка КриптоПро CSP или других сертифицированных средств

✅ Аккредитованные УЦ России:

ООО "КРИПТО-ПРО" - УЦ КриптоПро
АО "ПФ "СКБ Контур" - УЦ Контур
ООО "Компания Тензор" - УЦ Тензор
АО "Калуга Астрал" - УЦ Астрал
ПАО Сбербанк - УЦ Сбербанка
АНО "НИИ "Восход" - УЦ Восход-КА