Основное различие между разрешениями на основе области действия и пользовательскими разрешениями заключается в уровне детализации, на котором предоставляются разрешения.
Scope-based permissions (разрешения на основе области действия) — предоставляются на уровне ресурса или действия - конечной точки API. Эти разрешения определяют, какие действия могут выполнять пользовательские разрешения с этим ресурсом. Например, разрешать отправлять HTTP-запросы к определенной конечной точке API.
User-based permissions (пользовательские разрешения)— это разрешения, которые предоставляются на уровне пользователя или роли. Определяют, к каким ресурсам и действиям может получить доступ пользователь или роль во всей системе. Например, пользовательское разрешение может предоставлять пользователю доступ ко всем файлам в определенной папке или разрешать пользователю выполнять любые HTTP-запросы к API.
Consent-based permissions (разрешения на основе согласия)— это разрешения, которые предоставляются конечным пользователем, явно дающим свое согласие на определенное действие или доступ к определенному ресурсу.
В модели разрешений на основе согласия пользователь должен явно дать свое согласие, прежде чем приложению или системе будет разрешено выполнить определенное действие или получить доступ к определенному ресурсу от его имени. Это может включать в себя отображение диалогового окна или сообщения о согласии для пользователя, объясняющего, для каких действий приложение или система запрашивает разрешение, и позволяющее пользователю предоставить или отклонить это разрешение.
Управление согласием в Среде Открытых банковских интерфейсов использует механизмы, принятые для доступа к финансовым данным, используеммые в Open Banking (OIDC + FAPI + consent-base permissions).
Данный процесс был разработан на площадке АФТ с учетом требований участников финвасового рынка, согласован с Банком России и отражен в документах по прикдадным стандартам Открытых банковских интерфейсов (прошло согласование ТК122) и в ТПКО (прошло согласование и утверждение Участников АФТ).
Это технический процесс, который включает использование API для облегчения обмена финансовыми данными потребителей со сторонними поставщиками, обеспечивая при этом защиту конфиденциальности и безопасности потребителя. Ниже приведены технические детали управления согласием Open Banking:
Когда пользователь инициирует процесс создания согласия, банк создает запрос на согласие с использованием API Open Banking. Запрос согласия содержит такую информацию, как имя пользователя, сведения об учетной записи и типы данных, которые будут переданы стороннему поставщику.
Затем запрос согласия отправляется пользователю по защищенному каналу, например через мобильное приложение или портал онлайн-банкинга. Пользователь может просмотреть запрос согласия и либо принять, либо отклонить его.
Пример: Пользователь хочет использовать приложение для управления личными финансами, чтобы отслеживать свои расходы. Он инициирует процесс создания согласия в своем банке, банк генерирует запрос на согласие, содержащий разрешения на управление данными о транзакцииях пользователя. Пользователь просматривает запрос на согласие и принимает его, позволяя приложению для управления личными финансами получить доступ к данным о транзакциях пользователя.
Как только пользователь принимает запрос на согласие, банк сохраняет данные о согласии в защищенной базе данных с помощью API Open Banking. Сведения о согласии включают идентификацию пользователя, типы данных, которые будут переданы (разрешения на доступ к данным - perrmissions), идентификацию стороннего поставщика и срок действия согласия.
Пример: Банк хранит информацию о согласии в защищенной базе данных и присваивает согласию уникальный идентификатор. Затем идентификатор согласия используется для получения сведений о согласии, когда сторонний поставщик запрашивает доступ к данным.
Когда сторонний поставщик запрашивает доступ к финансовым данным пользователя, банк извлекает информацию о согласии из базы данных с помощью API Open Banking. Банк решает, имеет ли сторонний поставщик право доступа к данным, проверяя их идентификацию и факт предоставления к ним доступа пользователем.
Пример: финтех-компания запрашивает доступ к данным о транзакциях пользователя. Банк получает информацию о согласии, используя идентификатор согласия, и проверяет, имеет ли финтех-компания право доступа к этим данным.
Банк проверяет сведения о согласии с помощью API-интерфейсов Open Banking, чтобы убедиться, что у стороннего поставщика есть необходимые разрешения для доступа к данным. Банк также проверяет, действительно ли согласие еще действует и не истек ли срок его действия.
Пример: банк проверяет детали согласия, а именно, активно ли согласие и есть ли у стороннего поставщика необходимые разрешения для доступа к данным.
После подтверждения согласия банк предоставляет стороннему поставщику доступ к запрошенным данным с использованием API Open Banking. API-интерфейсы обеспечивают безопасный и стандартизированный механизм доступа к данным.
Пример: Банк предоставляет финтех-компании конечную точку API для безопасного доступа к данным транзакций пользователя. Затем финтех-компания может использовать эту конечную точку для получения данных в режиме реального времени.
Пользователь может отозвать свое согласие в любое время с помощью API Open Banking. Когда пользователь отзывает свое согласие, банк обновляет статус согласия в базе данных, и доступ стороннего поставщика к данным прекращается.
Пример: Пользователь отзывает свое согласие через мобильное приложение, а банк обновляет статус согласия в базе данных. Затем доступ финтех-компании к данным прекращается.
Таким образом, управление согласием Open Banking используется в Среде Открытых банковских интерфейсов для обеспечения безопасного обмена финансовыми данными пользователей со сторонними поставщиками. Этот процесс включает в себя создание, хранение, извлечение, проверку, доступ к данным и отзыв согласия, которые работают вместе для защиты конфиденциальности и безопасности пользователя, позволяя при этом обмениваться финансовыми данными с авторизованными сторонними поставщиками.
Сервер авторизации отвечает за проверку согласия пользователя и предоставление токенов доступа сторонним поставщикам для доступа к запрошенным данным. Ниже перечислены процессы, участвующие в проверке согласия на сервере авторизации.
Когда сторонний поставщик запрашивает доступ к данным пользователя, поставщик отправляет запрос на сервер авторизации, который включает в себя идентификатор согласия пользователя и запрошенные области данных.
Пример: финтех-компания запрашивает доступ к балансу счета пользователя и данным о транзакциях.
Сервер авторизации извлекает сведения о согласии из системы управления согласием и проверяет согласие, используя идентификатор согласия, указанный в запросе. Сервер также проверяет, находится ли запрос в рамках согласия пользователя.
Пример: сервер авторизации получает данные о согласии пользователя из системы управления согласием и проверяет согласие. Сервер проверяет, авторизован ли финтех-компанией пользователь для доступа к балансу счета и данным транзакций.
Если согласие действительно, сервер авторизации выдает токен доступа стороннему поставщику, который содержит предоставленные области данных. Маркер доступа можно использовать для доступа к данным, находящимся на сервере ресурсов.
Пример: сервер авторизации выдает финтех-компании токен доступа, который содержит области данных для запроса баланса счета и данных транзакций.
Сервер ресурсов отвечает за хранение и предоставление доступа к финансовым данным пользователя. Ниже перечислены процессы, участвующие в проверке согласия на стороне сервера ресурсов.
Когда сторонний поставщик запрашивает доступ к данным пользователя, поставщик отправляет запрос на сервер ресурсов, который включает в себя токен доступа, полученный от сервера авторизации.
Пример: финтех-компания отправляет запрос на сервер ресурсов для доступа к балансу счета пользователя и данным транзакций, используя токен доступа, полученный от сервера авторизации.
Сервер ресурсов проверяет токен доступа, полученный от стороннего поставщика, проверяя подпись и срок действия. Если токен доступа действителен, сервер ресурсов предоставляет доступ к запрошенным данным.
Пример: Сервер ресурсов проверяет токен доступа, полученный от финтех-компании, и предоставляет доступ к балансу счета пользователя и данным о транзакциях.
После предоставления доступа сервер ресурсов предоставляет запрошенные данные стороннему поставщику через безопасную конечную точку API.
Пример: Сервер ресурсов предоставляет финтех-компании баланс счета пользователя и данные транзакций через безопасную конечную точку API.
Сервер авторизации отвечает за проверку согласия пользователя и выдачу токенов доступа сторонним поставщикам, а сервер ресурсов отвечает за хранение и предоставление доступа к финансовым данным пользователя.
Проверка согласия на сервере авторизации включает в себя проверку согласия и выдачу маркеров доступа, тогда как проверка согласия на сервере ресурсов включает проверку маркера доступа и предоставление доступа к запрошенным данным.
Рассмотренные выше примеры включают финтех-компанию, запрашивающую доступ к балансу счета пользователя и данным о транзакциях, а также серверы авторизации и ресурсов, проверяющие согласие и токены доступа для предоставления доступа к запрошенным данным.
Для предоставления доступа к ресурсу с токеном доступа и consent-base permissions, необходимо проверить действительность токена доступа, согласия и разрешений, предоставленных пользователем.
Для проверки токена доступа необходимо проверить подпись и срок действия токена. Это можно сделать, отправив запрос на точку интроспекции токена сервера авторизации.
Пример:
Предполагается, что токен доступа имеет следующее значение: 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=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKVKF6QfT4fwp
Если токен действителен, сервер авторизации ответит объектом JSON, содержащим информацию о токене.
HTTP Method: GET
Consent Endpoint: https://authorization-server.com/account-consent/{consentId}
Headers:
Authorization: Bearer {access token}
Если согласие действительно, сервер авторизации ответит объектом JSON, содержащим информацию о согласии и разрешениях связанных с ним.
Для проверки разрешений, предоставленных пользователем, необходимо проверить область действия (scope) в токене доступа и значения разрешений (permissions) в согласии.
Пример:
Токен доступа имеет следующие значения области действия и разрешений:
Согласие имеет следующие значения параметра permissions:
Это означает, что в данном случае мы имееем доступ к информации о счете пользователя, позволяющий вызывать методы, содержащие информацию о счетах пользователя, остатке на счете и информвцию об операциях.
GET /accounts - доступ предоставлен с ограничением (без объекта AccountsDetails), т.к. отсутствует разрешение ReadAccountsDetails
GET /balances - доступ предоставлен только к информации о списании
GET /payment-cards - отказ
Для проверки токена доступа с consent-base permissions необходимо проверить действительность токена доступа, согласия и разрешения, предоставленные пользователем.