Дисклеймер

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

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

Динамическая регистрация клиента на сервере авторизации ("СТО БР ФАПИ.СЕК-1.6-2024")

Регистрация клиента OpenAPI СТО БР ФАПИ.СЕК-1.6-2024
Шаги процесса:
  1. Загрузка параметров сервера (Discovery — /.well-known/openid-configuration).
  2. Получение SSA из каталога участников (openbankingrussia.ru) с использованием ГОСТ криптографии.
  3. Заполнение профиля клиента согласно стандарту (со всеми обязательными и рекомендованными полями).
  4. Подача заявки с SSA и генерация client_id (симуляция ответа сервера).
Российские особенности: Обязательное использование ГОСТ алгоритмов подписи, российских сертификатов для mTLS, и SSA от аккредитованного каталога участников.

1. Discovery сервера авторизации

Введите URL с окончанием .well-known/openid-configuration
(Минимальный набор: registration_endpoint, authorization_endpoint, token_endpoint, scopes_supported, grant_types_supported)

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

Прогресс заполнения
Имя организации/ПО. Например: "ООО Современный потребитель", "Мобильный банк 2025".
Публичная страница приложения.
Список callback-URL для авторизации, минимум один необходим (например, https://you-app.ru/oauth/callback).
Ответственные за интеграцию.
URL логотипа (PNG/JPG/SVG).
URL JWKS (актуально для private_key_jwt).
Открытый каталог: Официальный реестр ЦБ РФ для продуктивной среды
Внутренняя верификация: Банк самостоятельно проверяет и подписывает SSA
Песочница: Тестовая среда для разработки и отладки
JWT токен с метаданными организации и ПО. Обязательное поле для регистрации по СТО БР ФАПИ.СЕК-1.6-2024.
О различных источниках SSA и процессе получения
🏛️ Открытый каталог участников (openbankingrussia.ru)
  • Регистрация организации: POST /organization
  • Регистрация ПО: POST /organizations/{org_id}/software
  • Создание SSA: POST /software-statement
  • Получение SSA: GET /organization/{org_id}/software/{software_id}/software-statement

Структура SSA согласно спецификации каталога:

{
  "iss": "https://openbankingrussia.ru",
  "aud": "https://as.bank.ru", 
  "organization": {
    "org_id": "UUID организации",
    "org_name": "Название организации",
    "org_inn": "ИНН (10-12 цифр)",
    "org_kpp": "КПП (9 цифр)",
    "org_ogrn": "ОГРН (13 цифр)"
  },
  "software_statement_roles": [
    {
      "role": "payment_tpp",
      "authorisation_domain": "open_banking",
      "status": "active"
    }
  ]
}

🏦 Внутренняя верификация банка-поставщика

Банк самостоятельно проверяет организацию и выдает SSA:

  • Верификация документов: ЕГРЮЛ, лицензии, доверенности
  • Проверка полномочий: Подтверждение права действовать от имени организации
  • Создание SSA: Банк подписывает JWT своим ключом
  • Ответственность: Банк несет полную ответственность за верификацию
Структура SSA от банка:
{
  "iss": "https://api.sberbank.ru",
  "aud": "https://api.sberbank.ru",
  "internal_verification": true,
  "verification_method": "manual_document_check",
  "verified_by": "bank_compliance_officer",
  "organization": { /* те же поля */ }
}

🧪 Песочница/тестовая среда

Для разработки и тестирования интеграций:

  • Самоподписанные токены: Разработчик может создать свой SSA
  • Тестовые данные: Фиктивные организации и ИНН
  • Любые алгоритмы: Не обязательно ГОСТ
  • Упрощенная валидация: Минимальные проверки
⚠️ Только для разработки! Не используйте в продуктивной среде.
Что означают выбранные Scopes?
openidОбязательный scope для OpenID Connect аутентификации
profileДоступ к профилю пользователя: имя, фамилия и базовая информация
emailПолучение email адреса пользователя
offline_accessПолучение refresh_token для длительного доступа без повторной авторизации
accountsРоссийский scope: Доступ к информации о банковских счетах и балансах
paymentsРоссийский scope: Инициирование платежей и переводов
fundsconfirmationРоссийский scope: Подтверждение наличия средств на счете
Подробнее о вариантах Grant Types
authorization_codeКлассический поток для web-приложений с участием пользователя и redirect URI (самый безопасный способ получения токенов).
refresh_tokenПозволяет получать новые access_token без повторного входа пользователя. Используется для автоматических обновлений сессии.
client_credentialsПоток для получения токенов без пользователя, только по client_id/client_secret (например, B2B или внутренние сервисы).
implicitУстаревший вариант для одностраничных web-приложений без серверной части. Практически больше не используется из-за низкой безопасности.
Описание методов аутентификации
private_key_jwtРекомендуемый метод для ФАПИ: Аутентификация через подписание JWT приватным ключом клиента с использованием ГОСТ алгоритмов. Требует публикации JWKS с российскими криптографическими ключами.
tls_client_authАльтернативный метод: Взаимная TLS аутентификация (mTLS) с использованием российских сертификатов. Клиент должен иметь действующий сертификат от российского УЦ.
Настройки private_key_jwt
Алгоритм для подписания 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)
  • Указание параметра для идентификации клиента
Доверенные CORS-URL для web-клиентов (через запятую).
Версия приложения (например "1.0.0").
После регистрации скопируйте client_id. Это ваши ключевые сведения для OpenAPI-интеграции.

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

📋 Сертификаты для установки ГОСТ каналов:
Для работы с российскими алгоритмами ГОСТ необходимы сертификаты от аккредитованных удостоверяющих центров.
Корневой сертификат аккредитованного российского удостоверяющего центра для проверки цепочки доверия.
Сертификат клиента с ключевой парой ГОСТ для аутентификации и подписания.
Сертификат для установления защищенного ГОСТ TLS соединения с банком.
Полная цепочка сертификатов от клиентского до корневого УЦ для валидации.
⚠️ Требования к сертификатам ГОСТ:
  • Сертификаты должны быть выданы аккредитованным российским УЦ
  • Использование алгоритмов ГОСТ Р 34.10-2012 для ключевых пар
  • Хэширование по ГОСТ Р 34.11-2012 (Стрибог)
  • Соответствие требованиям ФЗ-63 "Об электронной подписи"
  • Регистрация в реестре доверенных сертификатов Минцифры
  • Поддержка КриптоПро CSP или других сертифицированных средств
✅ Аккредитованные УЦ России:
  • ООО "КРИПТО-ПРО" - УЦ КриптоПро
  • АО "ПФ "СКБ Контур" - УЦ Контур
  • ООО "Компания Тензор" - УЦ Тензор
  • АО "Калуга Астрал" - УЦ Астрал
  • ПАО Сбербанк - УЦ Сбербанка
  • АНО "НИИ "Восход" - УЦ Восход-КА