¶ Определения
| Наименование | Описание |
|---|---|
| Пользователь | Физическое или юридическое лицо, получающий услуги от Стороннего поставщика с использованием API через среду Открытых банковских интерфейсов. Выступает в роли потребителя Потребитель, |
| Сторонний поставщик | Хозяйствующий субъект, использующий Открытые банковские интерфейсы для доступа к банковскому счету Пользователя в целях предоставления информационных услуг (при осуществлении роли СПИУ), для осуществления переводов денежных средств (платежей) (при осуществлении роли СППУ) и для получения публичных данных в режиме реального времени (при осуществлении роли СППД). Сторонний поставщик может получить доступ к счету Пользователя, управляемому ППИУ через Открытые банковские интерфейсы, при согласии Пользователя. Сторонний поставщик отправляет сообщения запроса через Открытые банковские интерфейсы ПУ и получает соответствующие ответные сообщения от этого ПУ. |
| Поставщик услуг | Кредитная организация, публикующая Открытые банковские интерфейсы для предоставления услуг |
¶ Потребитель
Потребителем в контексте открытого банкинга может быть любое физическое или юридическое лицо, которое использует финансовые услуги и продукты. В рамках открытого банкинга потребители могут быть:
Физические лица: Включают в себя частных клиентов банков, которые используют банковские счета, кредитные карты, кредиты, дебетовые карты и другие финансовые продукты. Физические лица могут использовать открытый банкинг для доступа к своим финансовым данным через сторонние приложения и сервисы, чтобы управлять своими финансами более эффективно, получать персонализированные рекомендации и использовать инновационные финансовые продукты.
Малые и средние предприятия (МСП): Малые и средние предприятия также могут быть потребителями открытого банкинга, используя его для управления своими финансами, автоматизации процессов учета и платежей, а также для доступа к финансовой аналитике и другим инструментам для улучшения финансового управления.
Крупные корпорации и предприятия: Большие компании также могут использовать открытый банкинг для управления своими корпоративными финансами, автоматизации платежных процессов, мониторинга и анализа финансовых данных.
Стартапы и предприниматели: Стартапы и предприниматели могут использовать открытый банкинг для доступа к финансовым данным и инструментам для управления своими стартовыми капиталами, а также для создания инновационных финансовых продуктов и сервисов.
Стратегические партнеры и поставщики услуг: Кроме того, в качестве потребителей открытого банкинга могут выступать стратегические партнеры банков и финансовых компаний, которые используют открытый банкинг для интеграции своих услуг с финансовыми системами и предоставления дополнительных сервисов клиентам.
¶ Scope base permission и Consent-based permission
Разница между базовым разрешением области действия и базовыми разрешениями пользователя
Основное различие между разрешениями на основе области и разрешениями на основе пользователей заключается в уровне детализации, на котором предоставляются разрешения.
Scope base permission — предоставляются на уровне ресурса или действия - конечной точки API. Эти разрешения определяют, какие действия может выполнять с этим ресурсом. Например, разрешать отправлять HTTP-запросы к определенной конечной точке API.
Consent-based permissions — это разрешения, которые предоставляются пользователем, явно дающим свое согласие на определенное действие или доступ к определенному ресурсу.
В модели разрешений на основе согласия пользователь должен явно дать свое согласие, прежде чем приложению или системе будет разрешено выполнить определенное действие или получить доступ к определенному ресурсу от его имени. Это может включать в себя отображение диалогового окна или сообщения о согласии для пользователя, объясняющего, для каких действий приложение или система запрашивает разрешение, и позволяющее пользователю предоставить или отклонить это разрешение.
¶ Управление согласием
Управление согласием в Открытых банковских интерфейсах использует механизмы, принятые для доступа к финансовым данным (OIDC + FAPI + consent-base permission).
Данный процесс был разработан на площадке АФТ с учетом требований участников финвасового рынка, согласован с ЦБ РФ и отражен в документах по прикдадным стандартам ОБИ (прошло согласование ТК122 https://www.cbr.ru/fintech/acts/?la.search=&la.tagid=3&la.vidid=26&la.date.time=any&la.date.datefrom=&la.date.dateto=) и в ТПКО (https://wiki.openbankingrussia.ru/ru/customer-experience-design-requirements ).
Это технический процесс, который включает использование API для облегчения обмена финансовыми данными потребителей со сторонними поставщиками, обеспечивая при этом защиту конфиденциальности и безопасности потребителя. Ниже приведены технические детали управления согласием:
¶ Создание согласия:
Когда потребитель инициирует процесс создания согласия, банк создает запрос на согласие с использованием API. Запрос согласия содержит такую информацию, как имя потребителя, сведения об учетной записи и типы данных, которые будут переданы стороннему поставщику. Затем запрос согласия отправляется потребителю по защищенному каналу, например через мобильное приложение или портал онлайн-банкинга. Затем потребитель может просмотреть запрос согласия и либо принять, либо отклонить его.
Пример: потребитель хочет использовать приложение для управления личными финансами, чтобы отслеживать свои расходы. Они инициируют процесс создания согласия в своем банке, который генерирует запрос на согласие, содержащий данные их транзакции. Потребитель просматривает запрос на согласие и принимает его, позволяя приложению для управления личными финансами получить доступ к своим данным о транзакциях.
¶ Хранение согласия:
Как только потребитель принимает запрос на согласие, банк сохраняет данные о согласии в защищенной базе данных. Сведения о согласии включают идентификацию потребителя, типы данных, которые будут переданы (разрешения на доступ к данным - perrmission), идентификацию стороннего поставщика и срок действия согласия.
Пример: Банк хранит информацию о согласии в защищенной базе данных и присваивает согласию уникальный идентификатор. Затем идентификатор согласия используется для получения сведений о согласии, когда сторонний поставщик запрашивает доступ к данным.
¶ Получение согласия:
Когда сторонний поставщик запрашивает доступ к финансовым данным потребителя, банк извлекает информацию о согласии из базы данных с помощью API. Банк проверяет, имеет ли сторонний поставщик право доступа к данным, проверяя их идентификацию и предоставление им доступа потребителем.
Пример: финтех-компания запрашивает доступ к данным о транзакциях потребителя. Банк получает информацию о согласии, используя идентификатор согласия, и проверяет, имеет ли финтех-компания право доступа к данным.
¶ Подтверждение согласия:
Банк проверяет сведения о согласии с помощью API, чтобы убедиться, что у стороннего поставщика есть необходимые разрешения для доступа к данным. Банк также проверяет, действительно ли согласие еще действует и не истек ли срок его действия.
Пример: банк проверяет детали согласия, проверяя, активно ли согласие и есть ли у стороннего поставщика необходимые разрешения для доступа к данным.
¶ Доступ к данным:
После подтверждения согласия банк предоставляет стороннему поставщику доступ к запрошенным данным с использованием API. API-интерфейсы обеспечивают безопасный и стандартизированный механизм доступа к данным.
Пример. Банк предоставляет финтех-компании конечную точку API для безопасного доступа к данным транзакций потребителя. Затем финтех-компания может использовать эту конечную точку для получения данных в режиме реального времени.
¶ Отзыв согласия:
Потребитель может отозвать свое согласие в любое время с помощью API. Когда потребитель отзывает свое согласие, банк обновляет статус согласия в базе данных, и доступ стороннего поставщика к данным прекращается.
Пример: Потребитель отзывает свое согласие через мобильное приложение, а банк обновляет статус согласия в базе данных. Затем доступ финтех-компании к данным прекращается.
¶ Диаграмма последовательности предоставления согласия и доступа к данным пользователя в соответствии с СТО БР ФАПИ.СЕК-1.6
¶ Процессы на сервере авторизации и сервере ресурсов для проверки согласия:
¶ Сервер авторизации.
Сервер авторизации отвечает за проверку согласия потребителя и предоставление токенов доступа сторонним поставщикам для доступа к запрошенным данным. Ниже перечислены процессы, участвующие в проверке согласия на сервере авторизации:
¶ Запрос на авторизацию:
когда сторонний поставщик запрашивает доступ к данным потребителя, поставщик отправляет запрос на сервер авторизации, который включает в себя идентификатор согласия потребителя и запрошенные области данных.
Пример: финтех-компания запрашивает доступ к балансу счета потребителя и данным о транзакциях.
¶ Проверка согласия.
Сервер авторизации извлекает сведения о согласии из системы управления согласием и проверяет согласие, используя идентификатор согласия, указанный в запросе. Сервер также проверяет, находится ли запрос в рамках согласия потребителя.
Пример: сервер авторизации получает данные о согласии потребителя из системы управления согласием и проверяет согласие. Сервер проверяет, авторизован ли финтех-компанией потребитель для доступа к балансу счета и данным транзакций.
¶ Выдача токена:
если согласие действительно, сервер авторизации выдает токен доступа стороннему поставщику, который содержит предоставленные области данных. Маркер доступа можно использовать для доступа к данным с сервера ресурсов.
Пример: сервер авторизации выдает токен доступа к финтех-компании, который содержит области данных для баланса счета и данных транзакций.
¶ Сервер ресурсов:
Сервер ресурсов отвечает за хранение и предоставление доступа к финансовым данным потребителя. Ниже перечислены процессы, участвующие в проверке согласия на сервере ресурсов.
¶ Запрос данных:
когда сторонний поставщик запрашивает доступ к данным потребителя, поставщик отправляет запрос на сервер ресурсов, который включает в себя токен доступа, полученный от сервера авторизации.
Пример: финтех-компания отправляет запрос на сервер ресурсов для доступа к балансу счета потребителя и данным транзакций, используя токен доступа, полученный от сервера авторизации.Access Token
¶ Проверка токена доступа.
Сервер ресурсов проверяет токен доступа, полученный от стороннего поставщика, проверяя подпись и срок действия. Если токен доступа действителен, сервер ресурсов предоставляет доступ к запрошенным данным.
Пример. Сервер ресурсов проверяет токен доступа, полученный от финтех-компании, и предоставляет доступ к балансу счета потребителя и данным о транзакциях.
¶ Доступ к данным:
после предоставления доступа сервер ресурсов предоставляет запрошенные данные стороннему поставщику через безопасную конечную точку API.
Пример: Resource Server предоставляет финтех-компании баланс счета потребителя и данные транзакций через безопасную конечную точку API.
¶ Предоставление доступа к ресурсу с токеном доступа и consent-base permission
Для предоставления доступа к ресурсу с токеном доступа и consent-base permission, необходимо проверить действительность токена доступа, согласия и разрешений, предоставленных пользователем.
¶ Проверка токена доступа
Для проверки токена доступа необходимо проверить подпись и срок действия токена. Вы можете сделать это, отправив запрос на интроспекцию токена на сервер авторизации.
Пример.
Предполагая, что токен доступа "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKVKF6QfT4fwp",
Запрос на интроспекцию токена на сервер авторизации со следующими параметрами:
HTTP Method: POST
Token Introspection Endpoint: https://authorization-server.com/token/introspect
Headers:
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64 encoded client ID and client secret}
Body:
token={access token}Если токен действителен, сервер авторизации ответит объектом JSON, содержащим информацию о токене.
¶ Проверка согласия.
Проверка состояние и срока действия согласия
¶ Получение информации о согласии
HTTP Method: GET
Consent Endpoint: https://authorization-server.com/account-consent/{consentId}
Headers:
Authorization: Bearer {access token}Если согласие действительно, сервер авторизации ответит объектом JSON, содержащим информацию о согласии и разрешениях связанных с ним.
¶ Проверка разрешений:
Для проверки разрешений, предоставленных пользователем, необходимо проверить область действия (scope) в токене доступа и значения разрешений (permission) в согласии
Пример:
Токен доступа имеет следующие значения области действия и разрешений:
- Scope: openid profile accounts
- Permission: read
Согласие имеет следующие значения параметра permissions:
"ReadAccountsBasic", "ReadBalances", "ReadTransactionsDebits", “ReadTransactionsBasic”
Это означает, что в данном случае мы имееем доступ информации о счете клиента, позволяющую вызывать методы, содержащие информацию о счетах пользователя, остатке на счете и информвцию об операциях.
get /accounts - доступ предоставлен с ограничением (без объекта AccountsDetails), т.к. отсутствует разрешение ReadAccountsDetails
get /balances - доступ предоставлен
get /balances - доступ предоставлен только к информации о списании
get /payment-cards - отказ
¶ Заключение
Для проверки токена доступа , связанного с согласием пользователя, в случае consent-base permission в OIDC необходимо проверить действительность токена доступа, согласия и разрешений, предоставленных пользователем.