21 Кві, 2023

OIDC: Відкритий протокол аутентифікації

Penetration Testing as a service (PTaaS)

Tests security measures and simulates attacks to identify weaknesses.

Огляд для OIDC 

OpenID Connect (OIDC) - це протокол аутентифікації, побудований поверх OAuth 2.0, який дозволяє користувачам аутентифицироваться у веб-або мобільному додатку за допомогою сторонньої служби аутентифікації. IT забезпечує стандартизований спосіб доступу до ідентифікаційної інформації в різних додатках і послуги і підтримує єдиного входу (SSO), який дозволяє користувачам входити в систему один раз і отримувати доступ до декількох веб-додатків без необхідності кожного разу вводити свої облікові дані. OIDC був введений в 2014 році для усунення деяких недоліків OAuth 2.0, який в першу чергу був розроблений для цілей авторизації, а не аутентифікації. Він використовує веб-токени JSON (JWTs) для обміну ідентифікаційної інформацією між постачальником посвідчень і веб-додатком. OIDC підтримує кілька різні типи потоків і областей застосування, кожна з яких призначена для конкретного варіанта використання. 

Історія OIDC 

Протокол OpenID Connect (OIDC) був розроблений в 2014 році як спосіб поліпшити оригінальний протокол аутентифікації OpenID, який був представлений в 2005 році, але не отримав широкого розповсюдження із-за своєї складності та відсутності стандартизації. OIDC був розроблений таким чином, щоб бути більш простим і гнучким, ніж його попередник, і забезпечувати стандартизований спосіб доступу до ідентифікаційної інформації в додатках і службах. 

До впровадження OIDC розробники зазвичай використовували OAuth 2.0 для забезпечення аутентифікації для своїх додатків, хоча OAuth 2.0 був в основному розроблений для цілей авторизації, а не аутентифікації. Це призвело до низки проблем, таких як необхідність для розробників впроваджувати свої власні механізми аутентифікації, що призвело до невідповідностям і вразливостей в системі безпеки. 

У відповідь на ці виклики група лідерів галузі, включаючи Google, Microsoft і Yahoo, в 2007 році заснувала OpenID Foundation для сприяння розробки та впровадження відкритих стандартів управління ідентифікацією. Основна увага фонду було зосереджено на розробці нового протоколу аутентифікації, який ґрунтувався б на OAuth 2.0 і усував деякі з його недоліків. 

Результатом цих зусиль стало впровадження OIDC в 2014 році. OIDC був розроблений як простий, гнучкий і масштабований протокол, який можна було б використовувати для широкого спектру варіантів використання, від входу в соціальну мережу до управління корпоративною ідентифікацією. Він був побудований поверх OAuth 2.0, який забезпечив основу для безпечного зв'язку між різними сторонами. 

OIDC був розроблений для забезпечення зворотної сумісності з OAuth 2.0, що означало, що розробники могли використовувати свою існуючу інфраструктуру OAuth 2.0 і додавати поверх неї функціональність OIDC. Це спростило розробникам впровадження OIDC і почало використовувати його в своїх додатках. 

Ключові особливості OIDC 

OIDC володіє кількома ключовими функціями, які роблять його популярним вибором для розробників, яким необхідно впровадити аутентифікацію в свої додатки. У цьому розділі ми детально розглянемо деякі ключові функції OIDC. 

Аутентифікація користувача  

Однією з основних цілей OIDC є спрощення процесу аутентифікації для кінцевих користувачів. OIDC дозволяє користувачам аутентифицироваться стороннього постачальника посвідчень особи (IDP), позбавляючи користувачів від необхідності запам'ятовувати кілька імен користувачів і паролів для різних додатків. IDP аутентифікує користувача і відправляє назад додатком ідентифікаційний маркер, який може бути використаний для перевірки особи користувача. Це робить процес аутентифікації більш безпечним і простим для кінцевих користувачів. 

Веб-токени JSON (JWTs)  

OIDC використовує веб-токени JSON (JWTs) для обміну ідентифікаційної інформацією між IDP додатком. JWT компактні, безпечні для URL-адрес і прості в аналізі, що робить їх ідеальним форматом для обміну ідентифікаційної інформацією. JWT складається з трьох частин: заголовка, корисного навантаження і підпису. Заголовок містить інформацію про JWT, таку як алгоритм, використовуваний для його підпису. Корисна навантаження містить ідентифікаційну інформацію, таку як ім'я користувача та адресу електронної пошти. Підпис використовується для перевірки автентичності JWT. 

Єдиного входу (SSO)  

OIDC підтримує єдиного входу (SSO), який дозволяє користувачам входити в систему один раз і отримати доступ до декількох додатків без необхідності кожного разу вводити свої облікові дані. Це досягається за рахунок використання JWT, які використовуються для обміну ідентифікаційної інформацією між IDP додатком. Як тільки користувач увійде в IDP, він зможе отримати доступ до декількох додатків без необхідності повторного введення своїх облікових даних. 

Авторизація  

OIDC побудований поверх OAuth 2.0, який забезпечує основу для безпечного зв'язку між різними сторонами. OAuth 2.0 в першу чергу призначений для цілей авторизації, але OIDC будується поверх нього також для забезпечення аутентифікації. OIDC дозволяє клієнтам отримувати авторизацію від користувачів для доступу до їх захищених ресурсів, таким як їх адресу електронної пошти або події календаря. 

Зворотна сумісність з OAuth 2.0 

OIDC розроблений таким чином, щоб бути назад сумісним з OAuth 2.0, що означає, що розробники можуть використовувати свою існуючу інфраструктуру OAuth 2.0 і додавати поверх неї функціональність OIDC. Це дозволяє розробникам легко впровадити OIDC і почати використовувати його в своїх додатках. 

Розширюваність  

OIDC розроблений таким чином, щоб бути гнучким і розширюваним, що означає, що його можна налаштувати у відповідності з потребами різних варіантів використання. OIDC підтримує кілька різних типів потоків, кожен з яких призначений для конкретного варіанта використання. Це дозволяє розробникам легко впроваджувати OIDC в свої додатки і налаштовувати його у відповідності зі своїми конкретними потребами. 

Стандартизація  

OIDC - це відкритий стандарт, який підтримується OpenID Foundation. Це означає, що він широко прийнятий і підтримується великою кількістю постачальників посвідчень особи і розробників додатків. Стандартизація OIDC спрощує розробникам впровадження її в свої додатки, а постачальникам посвідчень - її підтримку. 

Таким чином, OIDC - це гнучкий, розширюваний і стандартизований протокол аутентифікації, який надає користувачам простий і безпечний спосіб аутентифікації веб-і мобільних додатках. Його підтримка JWTs, єдиного входу і зворотна сумісність з OAuth 2.0 робить його популярним вибором для розробників, яким необхідно реалізувати аутентифікацію в своїх додатках. Його розширюваність і стандартизація роблять його гнучким і широко поширеним протоколом, який може бути налаштований у відповідності з потребами різних варіантів використання. 

Як працює OIDC? 

OpenID Connect (OIDC) - це протокол аутентифікації, який дозволяє користувачам перевіряти справжність та дозволити доступ до веб-додатків за допомогою стороннього постачальника посвідчень (IdP), якому довіряють як користувач, так і додаток. OIDC побудований поверх OAuth 2.0, який є стандартним протоколом для авторизації. У цьому розділі ми детально обговоримо, як працює OIDC. 

Користувач ініціює запит на аутентифікацію: В процес аутентифікації починається, коли користувач ініціює запит на аутентифікацію для доступу до захищеного ресурсу у веб-додатку. Запит відправляється клієнту OIDC, який є додатком, що вимагає аутентифікації користувача. 

Клієнт OIDC відправляє запит на авторизацію IdP: Потім клієнт OIDC відправляє запит на авторизацію IdP. Цей запит включає ідентифікаційні дані клієнта, запитувану область доступу та URL-адресу перенаправлення, куди користувач буде відправлений після завершення процесу аутентифікації. 

IdP аутентифікує користувача: Потім IdP аутентифікує користувача. Це може включати в себе введення користувачем імені користувача і пароля або використання більш просунутою форми аутентифікації, такий як багатофакторна аутентифікація (MFA). Як тільки користувач автентифікований, IdP генерує токен доступу і відправляє його назад клієнтові OIDC. 

Клієнт OIDC перевіряє маркер доступу: Потім клієнт OIDC перевіряє токен доступу, отриманий від IdP. Це включає в себе перевірку підпису сертифіката, дати закінчення терміну дії та іншої інформації, щоб переконатися, що токен дійсний і не був підроблений. 

Клієнт OIDC запитує інформацію про користувача у IdP: Якщо токен доступу дійсний, клієнт OIDC потім відправляє IdP запит на отримання інформації про користувача. Цей запит містить маркер доступу, а також запит на конкретну інформацію про користувача, таку як ім'я, адреса електронної пошти та інші атрибути. 

IdP відправляє інформацію про користувача клієнту OIDC Потім IdP відправляє запитану інформацію про користувача клієнту OIDC. Ця інформація зазвичай представлена у формі веб-токена JSON (JWT), який містить ідентифікаційну інформацію користувача, а також будь-які додаткові твердження, запитані клієнтом OIDC. 

Клієнт OIDC перевіряє справжність користувача Нарешті, клієнт OIDC може автентифікувати користувача на основі інформації, отриманої від IdP. Якщо користувач успішно пройшов аутентифікацію, йому надається доступ до захищеного ресурсу веб-додатки. 

Таким чином, протокол OIDC надає користувачам безпечний спосіб аутентифікації та авторизації доступу до веб-додатків. Використовуючи надійного постачальника посвідчень, користувачі можуть проходити аутентифікацію один раз, а потім отримувати доступ до декількох додатків без необхідності кожного разу повторно вводити свої облікові дані. Це робить процес аутентифікації більш спрощеним і зручним для користувачів, а також підвищує безпеку за рахунок зниження ризику крадіжки пароля і інших форм шахрайства з особистими даними.

Чим OpenID Connect відрізняється від OAuth 2.0  

OpenID Connect (OIDC) і OAuth 2.0 є широко використовуваними протоколами для управління ідентифікацією та доступом в Інтернеті. Хоча у них багато спільного, між цими двома протоколами є деякі важливі відмінності, які варто відзначити. У цьому розділі ми обговоримо основні відмінності між OIDC і OAuth 2.0. 

Мета Основна відмінність між OIDC і OAuth 2.0 полягає в їх призначенні. OAuth 2.0 - це в першу чергу протокол для авторизації, тоді як OIDC - це протокол для аутентифікації. OAuth 2.0 використовується для надання стороннім додаткам доступу користувача до ресурсів без надання їм повного доступу до облікового запису користувача. OIDC, з іншого боку, використовується для аутентифікації користувача та надання йому безпечного способу доступу до ресурсів в декількох додатках. 

Аутентифікація Хоча OAuth 2.0 можна використовувати для аутентифікації він не був розроблений спеціально для цієї мети. OIDC, з іншого боку, включає в себе функції, спеціально розроблені для аутентифікації. OIDC дозволяє делегувати аутентифікацію користувача довіреній сторонньому постачальнику посвідчень, який може надавати розширені функції аутентифікації, такі як багатофакторна аутентифікація (MFA). 

Інформація про користувача OIDC включає стандартний спосіб запиту та отримання інформації, у той час як OAuth 2.0 цього не робить. З допомогою OIDC, коли користувач проходить аутентифікацію, його ідентифікаційна інформація повертається в стандартизованому форматі JSON Web Token (JWT). Це дозволяє додаткам отримувати стандартний набір інформації, такої як ім'я, адресу електронної пошти та ідентифікатор користувача, без необхідності впроваджувати власні API для кожного постачальника посвідчень. 

Формат сертифіката Іншою ключовою відмінністю між цими двома протоколами є формат сертифіката, що використовується для автентифікації та авторизації. OAuth 2.0 використовує токени на пред'явника, які являють собою прості токени, відправляються в якості заголовків авторизації в HTTP-запиті. Ці токени відносно легко перехопити і відтворити, що робить їх менш безпечними для аутентифікації. OIDC, з іншого боку, використовує JWT, які включають цифровий підпис для перевірки їх справжності та запобігання підробки. 

Функції безпеки OIDC включає в себе декілька функцій безпеки, які не включені в OAuth 2.0. Наприклад, OIDC включає в себе можливість перевірки достовірності клієнтського додатка шляхом виконання запиту з використанням клієнтського секрету. OIDC також включає підтримку підписаних запитів, що допомагає запобігти повторні атаки і гарантує, що запити можуть бути відправлені тільки авторизованими сторонами. 

Хоча і OAuth 2.0, і OIDC використовуються для управління ідентифікацією та доступом в Інтернеті, вони служать різним цілям і включають різні функції. OIDC включає розширені функції аутентифікації і стандартизовану інформацію, що робить його більш відповідним для сценаріїв аутентифікації і єдиного входу (SSO). OAuth 2.0, з іншого боку, є в першу чергу протоколом для авторизації і не включає стандартизовану інформацію про користувача або розширені функції аутентифікації. 

Як використовувати OIDC 

Щоб використовувати OpenID Connect (OIDC) для аутентифікації, необхідно виконати кілька кроків. Ці кроки можуть змінюватись в залежності від конкретної реалізації OIDC, але в цілому задіяні наступні кроки: 

Виберіть постачальника посвідчень особи (IdP): Першим кроком у використанні OIDC для аутентифікації є вибір постачальника посвідчень (IdP), який підтримує OIDC. Популярні IDPL, які підтримують OIDC, включають Google, Microsoft і Okta. IdP надасть ідентифікатор клієнта OIDC і секрет клієнта, який буде використовуватися для аутентифікації за допомогою IdP. 

Додайте підтримку OIDC свого додаток: Наступний крок - додати підтримку OIDC в вашу програму. Зазвичай це включає в себе додавання клієнтської бібліотеки OIDC код вашої програми. Популярні клієнтські бібліотеки OIDC включають бібліотеку OpenID Connect для JavaScript (oidc-client-js) і бібліотеку Spring Security OAuth для Java. 

Налаштуйте додаток на використання IdP: Після того як ви додали підтримку OIDC в свій додаток, вам необхідно налаштувати свій додаток на використання IdP. Це включає в себе установку ідентифікатора клієнта і клієнтського секрету, що надаються IdP, а також налаштування будь-яких необхідних кінцевих точок і областей. 

Ініціюйте потік аутентифікації: Щоб ініціювати потік аутентифікації, вашому додатку необхідно перенаправити користувача до кінцевої точки авторизації IdP. Ця кінцева точка зазвичай вимагає, щоб користувач пройшов аутентифікацію за допомогою IdP, використовуючи своє ім'я користувача і пароль або інші форми аутентифікації, такі як багатофакторна аутентифікація (MFA). 

Отримаєте відповідь на аутентифікацію: Як тільки користувач пройде аутентифікацію за допомогою IdP, IdP перенаправляє користувача назад на перенаправлення URL вашого додатка. URL перенаправлення буде включати код авторизації, який може бути використаний для запиту сертифіката доступу до кінцевої точки токена IdP. 

Обміняйте код авторизації на токен доступу: Ваш додаток може використовувати код авторизації, отриманий від IdP, для запиту сертифіката доступу до кінцевої точки токена. Потім токен доступу можна використовувати для виконання аутентифікованих запитів до API IdP. 

Перевірте токен доступу: Перш ніж дозволити доступ до ресурсів вашого додатки, вашому додатку необхідно переконатися, що маркер доступу дійсний і не був підроблений. Зазвичай це включає в себе перевірку підпису сертифіката, дати закінчення терміну дії та іншої інформації. 

Використовуйте токен доступу для доступу до ресурсів: Як тільки токен доступу буде підтверджений, ваша програма зможе використовувати його для надсилання запитів до API IdP або до ресурсів вашого додатка. Токен доступу повинен бути включений в заголовок авторизації HTTP-запитів. 

Проблеми безпеки та їх усунення 

Як і будь-який інший протокол аутентифікації OpenID Connect (OIDC) має свій власний набір проблем безпеки, які необхідно враховувати для забезпечення безпечної аутентифікації. Нижче наведені деякі з поширених проблем безпеки, пов'язаних з OIDC, і заходи по виправленню, які можуть бути прийняті: 

Атаки типу "Людина посередині" (MitM): Атаки MitM можуть відбуватися, коли зловмисник перехоплює зв'язок між клієнтом і постачальником посвідчень. Це може призвести до того, що зловмисник зможе вкрасти облікові дані користувача або отримати несанкціонований доступ до даних користувача. 

Виправлення: Щоб запобігти атаки MitM, рекомендується використовувати HTTPS для шифрування зв'язку між клієнтом і постачальником посвідчень. Це гарантує, що зв'язок між двома сторонами не може бути перехоплена або підроблена зловмисником. 

Крадіжка токена: Якщо зловмисник отримує доступ до токена доступу користувача, він може використовувати його для висунення себе за користувача та доступу до ресурсів. 

Виправлення: Щоб запобігти крадіжці токенів, токени доступу повинні бути нетривалими і мати термін придатності. Крім того, рекомендується використовувати токени оновлення, які можна використовувати для отримання нового токен доступу після закінчення терміну дії старого. Токени доступу також повинні бути зашифровані і підписані, щоб запобігти несанкціоноване використання. 

Атаки на підробку міжсайтових запитів (CSRF): CSRF атаки можуть відбуватися, коли зловмисник відправляє запит постачальнику посвідчень від імені користувача. Це може призвести до того, що зловмисник зможе отримати облікові дані користувача або отримати доступ до його даних. 

Виправлення: Для запобігання атак CSRF рекомендується використовувати токени CSRF, які генеруються постачальником посвідчень і включаються до запити, що надсилаються клієнтом. Потім постачальник посвідчень може перевірити токен, щоб переконатися, що запит є законним і не відправлений зловмисником. 

Фішингові атаки: Фішингові атаки можуть відбуватися, коли зловмисник створює підроблену сторінку входу в систему постачальника посвідчень особи і обманом змушує користувача вводити свої облікові дані. Це може призвести до того, що зловмисник зможе вкрасти ваші облікові дані і отримати доступ до його даних. 

Виправлення: Для запобігання фішингових атак рекомендується навчати користувачів того, як ідентифікувати сторінки входу в систему законних постачальників посвідчень особи. Крім того, багатофакторна аутентифікація (MFA) може бути використана для забезпечення додаткового рівня безпеки та запобігання несанкціонованого доступу, навіть якщо зловмисник отримав облікові дані користувача. 

Небезпечне зберігання токенів доступу: Якщо токени доступу зберігаються небезпечно, зловмисник може легко отримати до них доступ і використовувати для отримання несанкціонованого доступу до даних користувача. 

Виправлення: Щоб запобігти небезпечне зберігання токенів доступу, токени доступу слід зберігати у безпечному місці, такому як сховище на стороні клієнта або сховище на стороні сервера, з відповідним шифруванням і контролем доступу. 

Щоб забезпечити безпечну аутентифікацію за допомогою OIDC, важливо вжити заходів щодо запобігання MitM-атак, крадіжки токенів, CSRF-атак, фішинг-атак і небезпечного зберігання токенів доступу. Дотримуючись рекомендованих заходів по виправленню, безпеку аутентифікації на основі OIDC може бути значно підвищена. 

Книги та посилання 

Ось кілька книг і посилань, пов'язаних із OpenID Connect (OIDC): 

"OAuth 2.0: початок роботи в області безпеки веб-API" Маттіаса Била: У цій книзі розглядаються основи OAuth 2.0 і OIDC і даються практичні рекомендації щодо їх впровадження в веб-додатки. 

"Спрощений OAuth 2.0" Аарона Пареки: Це безкоштовна онлайн-книга, яка надає просте і зрозуміле введення в OAuth 2.0 і OIDC. 

"OpenID Connect в дії" Прабата Сиривардены: Ця книга являє собою всеосяжне керівництво по впровадженню OIDC у веб-додатках і охоплює такі теми, як потоки аутентифікації, управління токенами і міркування безпеки. 

Ці ресурси можуть стати гарною відправною точкою для вивчення і впровадження OpenID Connect. 

Інші Послуги

Готові до безпеки?

зв'язатися з нами