Вопрос:
у нас должен использоваться именно: 7.1 Реализация протокола аутентификации с использованием сценария Гибридный поток?
Ответ:
да, использование гибридного потока обусловлено требованиями ИБ (обеспечение LoA3)
Согласно ФАПИ.ПАОК:
Реализация протокола OpenID Connect в случае инициации клиентом потока аутентификации конечного пользователя по отдельному каналу использует дополнительную конечную точку аутентификации и асинхронный метод для уведомления о ее результатах посредством следующих дополнительных действий:
Клиент выполняет запрос к конечной точке аутентификации по отдельному каналу, чтобы запросить аутентификацию конечного пользователя по отдельному каналу.
Сервер авторизации отвечает уникальным идентификатором конечного пользователя в фоновом режиме.
Клиент получает ID токен, токен доступа и опционально токен обновления с помощью режимов Poll (пункт 6.1.1), Ping (пункт 6.1.2) или Push (пункт 6.1.3), определяемых при регистрации клиента (пункт 6.2.2).
--п.3 - в каком режиме получаем токены?
по ФАПИ.СЕК:
Гибридный сценарий состоит из следующих действий:
1 Клиент генерирует запрос аутентификации, содержащий желаемые параметры запроса.
2 Клиент отправляет запрос на сервер авторизации.
3 Сервер авторизации аутентифицирует конечного пользователя.
4 Сервер авторизации получает согласие/авторизацию конечного пользователя.
5 Сервер авторизации возвращает конечного пользователя на клиент с передачей кода авторизации и в зависимости от типа ответа – одного или нескольких дополнительных параметров.
6 Клиент запрашивает ответ на конечной точке токена, используя код авторизации.
7 Клиент получает ответ, содержащий ID токен и токен доступа.
8 Клиент проверяет ID токен и извлекает идентификатор субъекта конечного пользователя (значение параметра sub).
Как у нас будет выглядеть публикация метаданных сервера авторизации (процедура OpenID Connect Discovery)?
{"issuer":"https://openbankingrussia.ru/as/aft","jwks_uri":"https://openbankingrussia.ru/jwks/sb-api.json","authorization_endpoint":"https://openbankingrussia.ru/as/aft/connect/authorize","token_endpoint":"https://openbankingrussia.ru/as/aft/connect/token","userinfo_endpoint":"https://openbankingrussia.ru/as/aft/connect/userinfo","scopes_supported":["openid","profile","email","accounts","payments"],"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"],"response_modes_supported":["form_post","query","fragment"],"grant_types_supported":["authorization_code","client_credentials","password","implicit"],"id_token_signing_alg_values_supported":["RS256"],"token_endpoint_auth_methods_supported":["client_secret_basic","private_key_jwt",],"id_token_encryption_alg_values_supported":["RSA-OAEP"],"Id_token_encryption_enc_values_supported":["A128CBC-HS256"]}5.4.4.1. Прежде чем запустить сервис аутентификации и авторизации клиентов, сервер авторизации должен опубликовать свои метаданные, описывающие его адрес и параметры доступа в ходе процедуры OpenID Connect Discovery
5.4.4.2. Настоящий стандарт не регламентирует способ получения адреса сервера авторизации. Этот адрес может предоставляться клиенту, например указанием его в документации на систему. Сервер авторизации может также запускать сервис, поддерживающий технологию WebFinger [25].
Структура данных объекта запроса аутентификации:
{
"typ": "JWT",
"alg": "PS256"
}
{
"response_type": "code id_token",
"state": "98d6691382344e7fb03c853739d0a988", --обязательный. Сторонний поставщик генерирует в произвольном формате и включает в запрос аутентификации условное значение идентификатора сессии.
"scope": "openid accounts offline_access", ---обязательный. Значения идентификаторов scope какие у нас будут?
Ответ: Прикладной scope "accouts" + стандартные по протоколу
"nonce": "642c0152a40a46bbb82bfda4e0799990", --обязательный. Случайное значение, используемое в качестве условного идентификатора сессии обмена сообщениями между Сторонним поставщиком и сервером авторизации.
"exp": 1618760589,
"max_age": 86400,
"claims": {
"userinfo": {
"openbanking_intent_id": { --где брать?
"value": "0c9df54a-b926-4853-acc2-e318c9bd7c33", --это идентификатор согласия, полученный в запросе согласия?
Да. это идентификатор ресурса согласия, который мы хотим авторизовать
"essential": true
}
},
"id_token": {
"openbanking_intent_id": {
"value": "0c9df54a-b926-4853-acc2-e318c9bd7c33",
"essential": true
},
"acr": {
"values": [
"urn:rubanking:sca",
"urn:rubanking:ca"
],
"essential": true
}
}
},
"aud": "https://sb-as.openbankingrussia.ru/sandbox/as/aft", --что указываем?
URI сервера авторизации
"iss": "4abd59d5970247969965a4f317a8f817", --что должно здесь передаваться?
"client_id": "4abd59d5970247969965a4f317a8f817", --идентификатор, полученный при регистрации?
в обоих случаях идентификатор клиента (client_id) полученный при регистрации
"redirect_uri": "https://localhost.ru/cb"
}
Структура ID Token в ответе на запрос авторизации:
{
"alg": "RS256",
"type": "JWT"
}
{
"nbf" : 1607716025,
"exp" : 1607716325,
"iss" : "https://sb0.openbankingrussia.ru/sandbox0/as/aft",
"aud" : "a8cadb2f65944ce2b3b92ba21336ad53", --обязательный. Идентификатор субъекта, представленного сервером авторизации, для которого выдается ID Token (должно быть равно значению "client_id" Клиента)
"iat" : 1607716025,
"nonce" : "642c0152a40a46bbb82bfda4e0799990",
"c_hash" : "OATPHzlrPpzO3PpMPLNknQ",
"s_hash" : "nVDApI-dUj2qei-oU9QeUw",
"sub" : "1e3a7d4a-d213-416d-b4d3-ac8000f9d1d0", ---обязательный. Уникальный идентификатор субъекта, выданный сервером авторизации конечному пользователю; Какое значение? как маппить идентификатор ВТБ и Альфы?
Если требуется маппить то можно вызвать метод get /userInfo - https://api.openbankingrussia.ru/userinfo-v1.0.1/#tag/Poluchenie-informacii-o-polzovatele
"auth_time" : 1607716014,
"name" : "test", --что должно здесь передаваться?
Имя пользователя или логин (это то что у вас должно быть в значении claims "name" на сервере авторизации
"openbanking_intent_id" : "1726c4f8-af35-41ef-bd84-569fb4647e1a",
"amr" : ["password"]
}
Запрос к конечной точке токена для обмена кода авторизации на токен доступа
client_assertion - обязательный. Утверждение, используемое для аутентификации клиента --какое значение (что здесь) необходимо передавать?
8.2 Пояснения к части диаграммы последовательности, относящейся к реализации сценария Гибридный поток
Началом Гибридного потока в приведенной диаграмме является действие, когда в ответ на запрос аутентификации сервер ППУ генерирует ресурс согласия (consentId) и передает его в ответе Стороннему поставщику;
в каком параметре consentId должен передаваться?
Структура созданного согласия зафиксирована?
{
"Data": {
"consentId": "9fbe4a9a-2a4f-4c90-850f-96af06f2574e", --идентификатор согласия поставщика данных (ВТБ/Альфы)? как его потом маппить с идентификатором в ПКС?
"creationDateTime": "2022-08-31T14:36:38.9990152+00:00",
"status": "AwaitingAuthorisation", --список статусов (значений) зафиксирован?
"statusUpdateDateTime": "2022-08-31T14:36:38.9990152+00:00",
"permissions": [
"ReadAccountsBasic",
"ReadAccountsDetail",
"ReadBalances",
"ReadTransactionsCredits",
"ReadTransactionsDebits",
"ReadTransactionsDetail",
"ReadTransactionsBasic"
],
"expirationDateTime": "2024-10-03T00:00:00+00:00",
"transactionFromDateTime": "2020-01-01T00:00:00+00:00",
"transactionToDateTime": "2024-12-31T00:00:00+00:00"
},
"Links": {
"self": "https://sb-rs.openbankingrussia.ru/sandbox/open-banking/v1.3/aisp/account-consents?consentId=9fbe4a9a-2a4f-4c90-850f-96af06f2574e"
},
"Meta": {
"totalPages": 1,
"firstAvailableDateTime": "0001-01-01T00:00:00+00:00",
"lastAvailableDateTime": "0001-01-01T00:00:00+00:00"
}
}