2.1. Процедура авторизації
Авторизація згідно зі стандартом OAuth 2.0 виконується у два етапи:
перший етап - отримання коду авторизації (authorization_code), параметр отриманий у запиті на веб-адресу callback_url, вказану в запиті п. 2.1.1;
другий етап - отримання коду доступу (access_token) на підставі коду авторизації (запит на адресу банку, значення параметра token_api_url, вказану під час реєстрації, п. 2.1.2).
Примітка. Веб-сторінка АБС банку, на якій користувач проходить процедуру автентифікації та погоджує процес передачі персональних даних, повинна бути брендована під конкретний банк, мати контактний телефон гарячої лінії з можливістю переходу користувача на веб-сторінку з контактною інформацією відповідного банку або форму зворотного зв'язку.
Якщо банк делегує функції автентифікації та авторизації сервіс-провайдеру, то описані нижче методи повинні бути реалізовані на стороні сервіс-провайдера.
2.1.1. Перехід на сторінку АБС методом GET (перший етап)
Структура запиту від ц.в. BankID НБУ до АБС, запит формується під час переадресації користувача з банера банку на веб-сторінці ц.в. BankID НБУ у такому форматі:
| GET https://example.bank.com/v1/bank/oauth2/authorize?response_type=code& HTTP/1.1 client_id=client_id& redirect_uri=callback_url& state=state |
Приклад запиту, за якого користувач перейде з веб-сторінки ц.в. BankID НБУ на веб-сторінку АБС банку:
Відповідь АБС банку:
У разі успішної автентифікації користувача на стороні АБС банку система банку повинна зробити запит із кодом авторизації на адресу параметра redirect_uri. Із даним запитом відбувається переадресація користувача до ц. в. BankID НБУ.
Приклад запиту від АБС банку:
| GET https: //id.bank.gov.ua/v 1 /bank/oauth2/callback/code? code=2d6f2318cb06cc2c97d948deb9799d608fl d5c97& state=2364fc5d-c6b6-4f99-87a9-lld2baa32484 |
Можливі помилки
Якщо під час здійснення вказаного запиту виникають помилки, то можливі дві ситуації:
• не вдалося автентифікувати запит (зокрема, ц.в. BankID НБУ не зареєстрований на стороні банку або не збігається значення певного параметра в запиті) або некоректний запит. У такому випадку опис помилки повинен бути відображений на веб-сторінці АБС.
• користувача вдалося автентифікувати на стороні АБС банку, проте сталася інша помилка - буде виконано запит із переадресацією користувача на адресу значення redirect_uri з можливими значеннями помилок у параметрах запиту, наприклад:
2.1.2. Запит на отримання коду доступу (access_token) методом POST
(другий етап)
Після отримання запиту з кодом авторизації ц.в. BankID ініціює запит на отримання коду доступу. Структура запиту від ц.в. BankID НБУ до АБС, за якого значення передаються у вигляді стрічки з параметрами на веб-адресу, що надана банком під час реєстрації token_api_url (п. 2) у такому форматі:
У відповідь АБС банку надає параметри та значення коду доступу в тілі запиту (body) у Json-форматі. Опціонально: у відповіді параметр зі значенням refresh_token зазначається, якщо термін дії коду доступу (access_token) досить короткий і на ресурсі АБС банку реалізований даний функціонал для оновлення запиту.
Приклад відповіді ц.в. BankID:
Можливі помилки
У разі виникнення помилок оброблення запиту рекомендуємо орієнтуватися на список кодів стану HTTP. У відповідь АБС надає параметри зі значеннями помилки, що спричинили відмову, і передає у тілі відповіді (body) у Json-форматі.
Приклад тіла відповіді з помилкою:
| ( "error": "invalid_grant", "error_description": "Invalid authorizathion code", "code": "2d6f2318cb06cc2c97d948deb9799d608f1d5c97" ) |
2.1.3. (Опціонально) Запит на продовження дії коду доступу (access_token) методом POST
Якщо зі сторони АБС банку отримана відповідь зі значенням параметра refresh_token, то для можливості продовжити дію вже отриманого коду доступу (без необхідності виконання всіх попередніх викликів) необхідно виконати такий запит.
Структура запиту від ц.в. BankID НБУ до АБС, значення передаються у вигляді стрічки з параметрами на вказану веб-адресу банку (надавалася банком під час реєстрації token_api_url, п. 2) у такому форматі:
У відповідь АБС банку надає параметри та значення коду доступу в тілі запиту (body) в Json-форматі.
Приклад відповіді АБС банку:
| HTTP/1.1 200 OK Content-Type: application/json ( "tokentype": "bearer", "access_token": "db8814c6d97cbad2a02db80e17d4676fab5914c6", "expires_in" :3600, ) |
2.2. Процедура отримання даних користувача
Надання даних відбувається на підставі коду доступу (access_token), отриманого в ході авторизації (згідно з попереднім пунктом). Код доступу передається в заголовку запиту (headers) у вигляді:
Authorization: "Bearer access_token"
Сторона ПП в запиті до ц.в. BankID НБУ повинна вказати, який саме набір даних стосовно користувача як клієнта банку потрібно передати у відповіді, а також надати свій посилений сертифікат шифрування у форматі base64. Ц.в. BankID НБУ переспрямовує отриманий запит на набір даних від ПП до АБС, у якому було здійснено автентифікацію користувача як клієнта банку.
Посилений сертифікат шифрування передається в атрибуті "cert" у форматі base64. Порядок шифрування анкети визначено в пункті 3.3 цієї специфікації.
Перелік необхідних даних указується згідно з допустимими полями у вигляді Json-об'єкту в тілі запиту (body). Якщо якесь із полів буде відсутнє зі сторони АБС, то замовлене поле не повертається або повертається зі значенням "null".
Приклад Json-об'єкта на запит персональних даних:
Тобто для отримання необхідних даних про користувача потрібно передати всі поля структури або підмножину полів, які необхідні (відсутність поля вказує на те, що дані щодо цього поля не потрібні).
2.2.1. Електронна анкета (з переліком та описом допустимих полів)
2.2.2. Запит даних користувача як клієнта банку
Для отримання даних щодо користувача направляється запит від ц.в. BankID НБУ до АБС за веб-адресою, наданою банком під час реєстрації (data_api_url) (п. 2). Параметри та значення передаються в тілі запиту (body) в Json-форматі.
Приклад запиту щодо даних до АБС банку:
Відповідь надається у вигляді Json-об'єкта, в якому банк надає свій посилений сертифікат шифрування та цифровий конверт, що містить підписані та зашифровані персональні дані. Посилений сертифікат шифрування банку міститься в атрибуті "cert" у форматі base64. Цифровий конверт із даними про користувача у підписаному та зашифрованому вигляді разом із зашифрованим ключем шифрування даних містяться в атрибуті "customerCrypto" у форматі base64.
Приклад відповіді:
Шифрування підписаних персональних даних відбувається відповідно до вимог до форматів криптографічних повідомлень, визначених наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 18.12.2012 № 739 (http://zakon3.rada.gov.ua/laws/show/z0108-13) (далі - Вимоги). Узгодження ключів за замовчуванням здійснюється з використанням статичного механізму. Якщо параметри криптографічного алгоритму статичної ключової пари відправника не еквівалентні параметрам криптографічного алгоритму статичної ключової пари одержувача, повинен здійснюватися перехід до застосування динамічного механізму узгодження ключів. Засоби криптографічного захисту інформації відправника та одержувача повинні підтримувати криптографічні алгоритми, визначені цими Вимогами.
АБС банку формує Json-об'єкт із персональними даними користувача у вигляді (приклад):
Після цього вказаний Json-об'єкт підписується електронним цифровим підписом банку і шифрується симетричним ключем сеансу (КШД - ключ шифрування даних за алгоритмом, визначеним у ДСТУ ГОСТ 28147-2009). Підписаний та зашифрований об'єкт формується у вигляді цифрового конверта згідно з Вимогами.
Примітка. Сам ключ шифрування даних шифрується узгодженим ключем (КШК - ключ шифрування ключа, симетричний ключ, який обчислюється за протоколом Діффі-Геллмана на підставі пари ключів - відкритого ключа шифрування ПП, отриманого з посиленого сертифіката ПП, та особистого ключа шифрування АБС банку).
Можливі помилки
У разі виникнення помилок оброблення запиту рекомендуємо орієнтуватися на список кодів стану HTTP. Якщо стан запиту дорівнює 200, то необхідно перевіряти тіло запиту (логічна помилка), в іншому випадку - це технічна помилка. Параметри зі значеннями помилки передаються в тілі запиту (body) у Json-форматі.
Приклад технічної помилки:
| ( "error": "invalid_token", "error_description": "Invalid access_token", "access_token": "db8814c6d97cbad2a02db80el7d4676fab5914c6" ) |
Приклад логічної помилки:
| ( "error": "invalid_cert", "error_description": "Sertificate not found at EUSignCP.EUPackHelper.EnvelopData(Byte[] data)", "code": "CL003" ) |
3. Захист інформації в системі BankID НБУ
3.1. Загальні положення
Передавання інформації між абонентами системи BankID НБУ повинно здійснюватися із забезпеченням конфіденційності та контролю цілісності.
ПП абонентів-надавачів послуг, абоненти-ідентифікатори (банки), центральний вузол системи BankID НБУ забезпечують ідентифікацію й автентифікацію у своїх інформаційно-телекомунікаційних системах із використанням криптографічного протоколу TLS (Transport Layer Security), вимоги до якого наведено нижче.
У системах абонентів-надавачів послуг, абонентів-ідентифікаторів (банків), центрального вузла системи BankID НБУ здійснюється реєстрація подій шляхом ведення журналу аудиту.
Журнал аудиту ПП абонента - надавача послуг повинен містити відомості про факт відправлення електронного запиту на ідентифікацію центральному вузлу системи BankID НБУ, отримання електронного підтвердження ідентифікації від центрального вузла системи BankID НБУ, результат розшифрування електронного підтвердження ідентифікації, результат перевірки ЕЦП, накладеного абонентом-ідентифікатором (банком).
Журнал аудиту абонента-ідентифікатора (банку) повинен містити відомості про факт звернення користувача системи BankID НБУ, результат опрацювання звернення користувача системи BankID НБУ, факт відправлення електронного підтвердження ідентифікації центральному вузлу системи BankID НБУ.
Журнал аудиту центрального вузла системи BankID НБУ повинен містити відомості про факт проходження електронного запиту на ідентифікацію від абонента - надавача послуг через центральний вузол системи BankID НБУ абоненту-ідентифікатору, про факт проходження електронного підтвердження ідентифікації від абонента-ідентифікатора через центральний вузол системи BankID НБУ абоненту - надавачу послуг.
Абоненти - надавачі послуг, абоненти-ідентифікатори, адміністратори абонентських вузлів, адміністратор центрального вузла системи BankID НБУ мають право самостійно визначати додаткові події, що фіксуються у відповідних журналах аудиту.
Усі записи в журналах аудиту повинні містити опис події, дату і час події, а також забезпечувати ідентифікацію суб'єкта, який ініціював подію.
Журнали аудиту повинні мати захист від несанкціонованого доступу, модифікації та знищення (руйнування).
Взаємодія центрального вузла системи BankID НБУ із системами абонентів - надавачів послуг та абонентів-ідентифікаторів здійснюється виключно з використанням параметрів та адрес, узгоджених з адміністратором центрального вузла системи BankID НБУ.
3.2. Вимоги до використання криптографічного протоколу TLS та відповідних сертифікатів відкритих ключів
Портали абонентів - надавачів послуг (ПП), абоненти - ідентифікатори (банки), центральний вузол системи BankID НБУ для встановлення безпечного з'єднання між собою та з користувачами системи BankID НБУ повинні використовувати криптографічний протокол TLS не нижче версії 1.2, а також відповідні особисті ключі та сертифікати відкритих ключів.
У протоколі TLS допускаються різні криптографічні набори.
Криптографічний набір узгоджується між клієнтом та сервером під час встановлення з'єднання. Клієнт передає серверу список підтримуваних криптографічних наборів, а сервер обирає один із них для захисту інформації.
Сервери не повинні застосовувати криптографічні набори, які не використовують шифрування або коли для шифрування використовується алгоритм RC4 (у ролі EncryptionAlg встановлено NULL або RC4).
Для шифрування інформації повинні використовуватися симетричні криптографічні алгоритми з довжиною ключа не менш як 128 біт.
Не рекомендується застосовувати криптографічні набори, які для обміну ключами використовують статичний RSA. Довжина відкритого ключа RSA повинна бути не меншою ніж 2048 біт. Заборонено застосовувати криптографічні набори, які використовують попередньо узгоджений загальний секретний ключ (PSK).
Для узгодження сеансових ключів використовуються протоколи DHE та ECDHE. Довжина відкритого ключа для протоколу DH повинна бути не меншою ніж 2048 біт. Довжина відкритого ключа для протоколу ECDHE повинна бути не меншою ніж 256 біт.
Рекомендується використовувати такі криптографічні набори:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Абоненти - надавачі послуг, абоненти-ідентифікатори, центральний вузол системи BankID НБУ використовують сертифікати відкритих ключів розширеної перевірки (Extended Validation Certificates, далі - EV SSL сертифікат) у форматі X.509 версії 3.
Рекомендується використовувати браузери провідних розробників (таких як Apple, Google Inc., Microsoft Corporation, Mozilla Foundation, Opera Software ASA) та отримувати EV SSL-сертифікати від центрів сертифікації ключів (certificate authority/CA), довірених для відповідних браузерів.
EV SSL-сертифікат не повинен мати тип Wildcard. У розширенні "Додаткові дані підписувача" ("subjectAlternativeName") EV SSL сертифіката не допускається використання URL, який відрізняється від URL, зазначеного в "реквізиті підписувача" ("commonName") поля "Підписувач" ("subject").
3.3. Вимоги до забезпечення конфіденційності та контролю цілісності електронної анкети
Абонент - ідентифікатор (банк) перед передаванням електронного підтвердження ідентифікації з інформацією про користувача через систему BankID НБУ послідовно виконує такі операції:
- накладає на електронне підтвердження ідентифікації свій електронний цифровий підпис відповідно до вимог Закону України "Про електронний цифровий підпис" ;
- шифрує підписане електронне підтвердження ідентифікації з використанням посиленого сертифіката шифрування того абонента - надавача послуг, якому передає електронну анкету.
Шифрування/розшифрування електронного підтвердження ідентифікації відбувається згідно з алгоритмами та правилами шифрування даних, визначеними Вимогами до форматів криптографічних повідомлень, які затверджені наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 18.12.2012 № 739 (http://zakon3.rada.gov.ua/laws/show/z0108-13). Узгодження ключів шифрування за умовчанням здійснюється з використанням статичного механізму. Якщо параметри криптографічного алгоритму статичної ключової пари відправника не еквівалентні параметрам криптографічного алгоритму статичної ключової пари одержувача, повинен здійснюватися перехід до застосування динамічного механізму узгодження ключів.
Абонент-ідентифікатор накладає на електронне підтвердження ідентифікації свій електронний цифровий підпис із використанням формату "ЕЦП з повним набором даних перевірки" (CAdES-X Long відповідно до ДСТУ ETSI TS 101733:2009).
Накладення електронного цифрового підпису на електронне підтвердження ідентифікації здійснюється відповідно до Вимог до формату підписаних даних, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20.08.2012 № 1236/5/453 та зареєстрованих у Міністерстві юстиції України 20.08.2012 за № 1401/21713 (зі змінами).
Додаток 8
до Публічної пропозиції
Національного банку України
на укладення Єдиного договору
банківського обслуговування
та надання інших послуг
Національним банком України
СПЕЦИФІКАЦІЯ
взаємодії з системою BankID Національного банку України (взаємодія системи BankID НБУ з порталом послуг)
Аркуш контролю версій
| Версія | Дата | Опис |
| 1.0 | 13.07.2015 | Перша версія для загального обговорення |
| 1.1 | 27.07.2015 | Виправлення зауважень, отриманих від НБУ |
| 2.0 | 30.11.2015 | Зміна версії |
| 3.0 | 04.12.2015 | Доповнення протоколу взаємодії системи BankID НБУ - Банк: можливість взаємодії через сервіс-провайдера; передача даних анкети користувача в зашифрованому вигляді |
| 3.1 | 10.03.2016 | Виправлення URL (додавання /bank/) |
| 3.2 | 13.10.2016 | Додавання розділу щодо захисту інформації |
| 3.3 | 31.10.2016 | Унесені правки для узгодження тексту розділів із змістом розділу щодо захисту інформації |
| 4 | 17.10.2018 | Унесено правки та роз'яснення щодо порядку запитів у процесі взаємодії, доповнено види можливих помилок та роз'яснення щодо загального підходу шифрування/розшифрування даних. Доповнено перелік допустимих полів для запиту персональних даних. Унесено виправлення для узгодження з новою редакцією Положення про систему BankID Національного банку України. Зміна версії |
Глосарій
| № | Термін, скорочення | Визначення |
| 1 | АБС | Автоматизована банківська система - автоматизована система банку - комплекс програмно-технічних засобів, спрямований на автоматизацію банківської діяльності. Забезпечує інтеграцію різних підсистем, кожна з яких спрямована на виконання тієї чи іншої сфери діяльності банку. У даному документі використовуються такі приклади підсистем АБС: ІБ (інтернет-банкінг). |
| 2 | Авторизація | Процес надання фізичній особі прав на виконання певних дій або доступу до ресурсів, а також процес перевірки (підтвердження) прав під час спроби виконання цих дій |
| 3 | Автентифікація | Процес перевірки достовірності. В системі BankID НБУ це електронна процедура, що дає змогу підтвердити електронну дистанційну ідентифікацію фізичної особи. |
| 4 | ІБ | Інтернет-банкінг - технологія дистанційного банківського обслуговування, доступна користувачу за допомогою звичайного браузера з будь-якого комп'ютера, який має вихід в Інтернет. |
| 5 | Ідентифікація | Ідентифікація - дистанційна ідентифікація - процес розпізнавання фізичної особи абонентами - надавачами послуг шляхом підтвердження автентифікації Користувача системи BankID НБУ абонентом-ідентифікатором. |
| 6 | Посилений сертифікат шифрування | Сертифікат відкритого ключа, виданий акредитованим центром сертифікації ключів, який використовується в процесі обчислення узгодженого ключа шифрування ключів згідно з Вимогами до форматів криптографічних повідомлень (затверджені наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 18.12.2012 № 739). |
| 7 | ПП | Портал послуг - портал (web-сайт, web-портал) абонента - надавача послуг - суб'єкта надання адміністративних послуг, державного або недержавного органу, банку або небанківської установи, на якому ініціюється електронний запит на ідентифікацію користувачів із використанням системи BankID НБУ. |
| 8 | Система дистанційного обслуговування | Система надання банківських послуг користувачу без його безпосереднього звернення до відділення банку. Перед отриманням послуг користувач проходить попередню ідентифікацію та автентифікацію в системі за встановленою банком технологією. |
| 9 | Центральний вузол системи BankID НБУ | Комплекс програмно-технічних засобів, відносно якого побудована взаємодія в системі BankID НБУ між ПП та АБС на базі протоколу OAuth2.0. Центральний вузол розміщено на ресурсах Національного банку України. |
| 10 | BankID НБУ | Комплекс програмно-технічних засобів та організаційно-технологічних заходів для забезпечення дистанційної ідентифікації користувачів під час інформаційної взаємодії між абонентами (ПП та АБС) в електронній формі з використанням банківських систем дистанційного обслуговування. |
| 11 | OAuth | Відкритий протокол авторизації, який дає змогу третій стороні отримати обмежений доступ до захищених ресурсів користувача без необхідності передавати їй (третій стороні) логін та пароль (протокол розташований за веб-адресою http://oauth.net). У системі BankID НБУ використовується протокол версії 2.0. |
1. Загальна частина
1.1. Призначення документа
Опис функціональних вимог та процесу взаємодії Порталу послуг (далі - ПП) із центральним вузлом системи BankID НБУ.
1.2. Цілі створення сервісу
Забезпечення на ПП надійної та зручної ідентифікації користувача через систему BankID НБУ за участю банка (АБС), система якого передбачає ідентифікацію користувача як клієнта банку.
1.3. Концепція функціонування системи
Функціонально система складається з трьох основних блоків:
1. ПП (веб-портал послуг), на якому розміщені форми надання послуг у електронному вигляді (реєстрація/авторизація, замовлення довідок, унесення до реєстрів, надання банківських, небанківських та інших послуг). Під час входу на портал або замовлення послуги користувачу доступна можливість авторизації або ідентифікації за допомогою системи BankID НБУ у вигляді банера або кнопки.
Після натискання кнопки або банера "авторизація/вхід/ідентифікація за допомогою системи BankID НБУ" користувач із веб-сторінки ПП переадресовується на веб-сторінку вибору банку на центральному вузлі системи BankID НБУ, обирає банк, клієнтом якого він є, і спрямовується на веб-сторінку АБС відповідного банку для проведення процедури ідентифікації користувача.
У результаті успішного проходження процедури ідентифікації зі сторони АБС формується електронна анкета з персональними даними користувача (п. 2.2.), після чого користувач автоматично переадресовується назад на веб-сторінку ПП. Одночасно ПП відповідно до порядку отримання даних отримує від АБС через систему BankID НБУ підписану та зашифровану банком анкету з даними користувача.
2. Центральний вузол системи BankID НБУ, на якому розміщена веб-сторінка вибору банку та програмні процедури запиту/передачі даних між АБС та ПП на базі протоколу OAuth2.0.
Після вибору користувачем банку на веб-сторінці центрального вузла системи BankID НБУ користувач переадресовується на веб-сторінку системи дистанційного обслуговування відповідного банку, на якій користувач як клієнт банку проходить стандартну процедуру ідентифікації та автентифікації (наприклад, уводить логін та пароль доступу до ІБ).
У результаті успішного проходження процедури ідентифікації та автентифікації користувача між АБС банку, центральним вузлом системи BankID НБУ та ПП відбувається автоматична взаємодія отримання/передачі коду авторизації (authorization_code), коду доступу (access_token) та персональних даних.
3. Банк (АБС: веб-портал інтернет-банкінгу або іншого сервісу банку), на веб-сторінці якого, має бути реалізована форма ідентифікації користувача, програмні процедури автоматичного формування коду авторизації (authorization_code), коду доступу (access_token) та електронної анкети (п. 2.2.), накладення на неї електронного цифрового підпису банку, шифрування даних анкети і переспрямування цієї анкети до ПП.
Користувач, перейшовши на веб-сторінку АБС, має можливість ідентифікуватися як клієнт обраного банку, наприклад, за допомогою номера картки банку або з використанням логіна та пароля, отриманих від банку. У разі успішної автентифікації користувач автоматично переспрямовується на сторінку ПП для продовження отримання послуги. Одночасно АБС банку повинна здійснити такі дії:
сформувати код авторизації (authorization_code), за яким здійснюється запит на отримання коду доступу (access_token),
сформувати код доступу, за яким буде здійснено запит необхідних персональних даних користувача (згідно з протоколом OAuth 2.0);
у відповідь на запит персональних даних перевірити відкритий ключ ПП, отриманий у посиленому сертифікаті шифрування, та сформувати цифровий конверт із підписаними й зашифрованими персональними даними (формати підписаних та зашифрованих даних визначено наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України № 739 від 18.12.2012).
Банк може делегувати функцію ідентифікації користувача третій стороні, з якою у банка є договірні відносини відповідно до законодавства.
У такому випадку делеговані функції АБС реалізуються у відповідній автоматизованій системі сервіс-провайдера, при цьому веб-сторінка ідентифікації на сайті сервіс-провайдера повинна бути брендована під банк і містити контактний телефон та/або форму зворотного зв'язку з банком.
Сервіс-провайдер забезпечує перевірку автентичності користувача, генерацію коду авторизації користувача, надання і перевірку коду доступу та подальшу взаємодію з відповідним сервісом АБС банку для отримання електронної анкети з персональними даними користувача (п. 2.2.).
Персональні дані користувача від АБС банку передаються до сервіс-провайдера і далі до центрального вузла системи BankID НБУ у зашифрованому вигляді таким чином, щоб сервіс-провайдер не мав змоги ознайомитися зі змістом персональних даних. Вимоги до використання криптографічного протоколу захисту, сертифікатів ключів, забезпечення конфіденційності та контролю цілісності електронної анкети наведені у п. 3 цієї специфікації взаємодії.
2. Технічна архітектура системи
Взаємодія ПП із центральним вузлом системи BankID НБУ відбувається на базі протоколу OAuth2.0 згідно зі специфікацією, яка знаходиться за веб-адресою: https://tools.ietf.org/html/rfc6749. Рекомендовано використовувати готові рішення з веб-сайта http://oauth.net/2/ - секція "Code and Services", варіанти під різні платформи та мови програмування.
Ідентифікація користувача відбувається засобами АБС відповідного банку чи АБС сервіс-провайдера, який представляє інтереси банку. Дані, що передаються в запиті АБС до ПП, шифруються симетричним ключем сеансу або ключем шифрування даних за алгоритмом, визначеним у ДСТУ ГОСТ 28147-2009. В основі передачі даних лежить SSL-протокол.
Логіка роботи системи BankID НБУ побудована на організації звернень від ПП до АБС конкретного банку через єдиний шлюз, яким виступає центральний вузол системи BankID НБУ (далі - ц.в. BankID НБУ) та адресному передаванні необхідних даних від АБС банку до ПП у підписаному та зашифрованому вигляді. Усі абонентські вузли (як ПП, так і банків) взаємодіють виключно через ц.в. BankID НБУ.
Для підключення ПП до ц. в. BankID НБУ уповноважена особа від ПП надає DNS-адресу порталу послуг (client_host), із якої будуть ініціюватися запити від ПП до ц. в. BankID, та адресу для зворотного виклику (callback_url). Адміністратор ц. в. BankID НБУ видає уповноваженій особі ПП унікальні ідентифікатори параметрів з'єднання (client_id, client_secret). Усі зазначені параметри є обов'язковими, мають бути фіксовані і не повинні містити змінних параметрів (зміни в адресах повинні узгоджуватися з головним адміністратором системи BankID НБУ).
2.1 Процедура авторизації
Авторизація згідно зі стандартом OAuth 2.0 виконується у два етапи:
перший етап - отримання коду авторизації (authorization_code), параметр отриманий у запиті на веб-адресу callback_url, указану в запиті п. 2.1.1.;
другий етап - отримання коду доступу (access_token) на підставі коду авторизації (запит на адресу ц. в BankID НБУ згідно з п. 2.1.2.).
2.1.1 Перехід на сторінку ц. в. BankID НБУ методом GET (перший етап)
Структура запиту від ПП до ц.в. BankID НБУ - запит формується під час переадресації користувача з кнопки "авторизація/вхід/ідентифікація за допомогою системи BankID НБУ" на веб-сторінці ПП у наступному форматі: