Що таке OAuth 2.0 і як працює авторизація через токени

Свого часу, років 20 тому, користувачам онлайн-сервісів доводилось створювати окремий логін і пароль практично для кожного онлайн-сервісу чи веб-майданчику в мережі. На щастя ті часи давно в минулому, сьогодні майже усі сервіси дозволяють залогінитись в один клік – через Google або Facebook. 

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

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

Основи OAuth 2.0

Почнемо з базрвих питань. Що таке OAuth 2.0? Це відкритий стандарт авторизації, який дозволяє користувачам надавати доступ до своїх даних на одній платформі іншій без передачі пароля. Першу версію OAuth у 2006 році було створено командою Twitter. Друга версія вийшла під проводом робочої групи IETF у 2012 році – вона стала відповіддю на потреби мережі в максимально доступній та безпечній системі авторизації для веб- і мобільних додатків.

Чи можна у двох словах пояснити, як працює OAuth 2.0? Принцип роботи простий: замість пароля для входу використовуються токени доступу (access token). Користувач підтверджує дозвіл через свій акаунт (наприклад, у Facebook чи Google), після чого сервіс отримує тимчасовий токен. Цей токен і є ключем до даних або дій від імені користувача. Таким чином, паролі залишаються у безпеці, а сторонні застосунки мають лише обмежені права доступу.

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

OAuth 2.0 застосовується у всіх випадках, де виникає потреба делегувати доступ: 

• Єдиний вхід (Single Sign-On, SSO. Коли користувачу потрібно надати доступ до одного сервісу (наприклад, Trello або Miro) через обліковий запис іншого (наприклад, Google або Slack).

• Доступ до API. Коли сторонній додаток (наприклад, мобільна гра) має отримати доступ до профілю користувача у соціальній мережі, щоб, наприклад, опублікувати результат користувача або знайти друзів.

• Інтеграція сервісів. Коли користувач дозволяє одному сервісу отримувати дані з іншого. Наприклад, фітнес-додаток отримує доступ до стримінгового сервісу Spotify, аби запустити плейлист користувача. 

• Системи з мікросервісною архітектурою. Для безпечного та безшовного доступу одних мікросервісів до ресурсів інших.

• Доступ сервісу до даних користувача. Наприклад, коли додаток для обробки фотографій отримує доступ до особистої галереї в Google Photos без необхідності надання логіна/пароля.

• Системи IoT. Для авторизації смарт-пристроїв та безпечного доступу до хмарних сервісів.

Ключові терміни та ролі у процесі авторизації

Давайте заглибимось у внутрішню механіку OAuth2. Як працює та з чого складається цей стандарт? Розуміння ключових термінів і ролей допоможе краще вхопити суть технології, аби застосовувати її безпечно та ефективно. Розберемо основних учасників процесу та їхні функції. 

• Resource Owner (Власник ресурсів)

Власник ресурсів – це користувач, який володіє певними даними (наприклад, контактами чи файлами)  і наділений повноваженнями надавати доступ до них. Наприклад, власник Google-акаунту надає сторонньому застосунку доступ до своїх контактів, фото чи календаря. В логіці  OAuth 2.0 Resource Owner не передає стороннім системам пароль до акаунту, а лише підтверджує згоду на доступ.

• Клієнт (Client)

Клієнт — це додаток (веб, мобільний чи серверний), який хоче отримати доступ до даних власника ресурсів. У ролі клієнта може виступати що завгодно: мобільна гра, платформа CRM, фітнес-додаток тощо. Клієнт реєструється на сервері авторизації, отримуючи ідентифікатор (Client ID) і, за потреби, секретний ключ (Client Secret). Він ініціює процес авторизації, перенаправляючи користувача на сервер авторизації. Він також використовує отриманий access token для запитів до сервера ресурсів. Наприклад, додаток для управління проєктами виступає клієнтом, коли запитує доступ до Google Drive.

• Авторизаційний сервер (Authorization Server)

Це ключовий компонент безпеки, сервіс видачі access token. Його основне завдання – перевірити особу користувача (з логіном/паролем, багатофакторною аутентифікацією тощо) та коректно видати клієнту токен доступу. Наприклад, це сервер Google, який підтверджує, що користувач залогінився і дозволив доступ до ресурсів. Авторизаційний сервер ніколи не зберігає ваші дані, він лише керує дозволами.

• Сервер ресурсів 

Це сховище, де зберігаються дані користувача: фото в Google Drive, контакти у Facebook історія транзакцій в банківському додатку тощо. Сервер ресурсів перевіряє токен доступу OAuth2, отриманий від клієнта, і якщо проблем не виявлено – надає доступ до даних.  Сервер ресурсів не займається авторизацією користувача; він лише перевіряє дійсність токена. У деяких випадках сервери авторизації та ресурсів можуть бути частиною однієї системи (як у Google), але їхні функції розділені для безпеки.

Така авторизація через токени врешті забезпечує користувачам гнучкість, простоту та безпеку даних. 

Потоки авторизації в OAuth 2.0

OAuth 2.0 не є одним універсальним сценарієм на всі випадки життя. Він пропонує цілий набір різних потоків (flows), які підходять для різних типів застосунків та рівнів безпеки. Потік врешті визначає, як саме клієнт отримує токен авторизації. Розглянемо ключові потоки авторизації OAuth. 

• Authorization Code Flow: найпоширеніший варіант

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

Наприклад, реалізація потоку Authorization Code дозволяє додатку для управління проєктами отримувати доступ до Google Calendar. Цей потік ідеальний для додатків із серверною частиною, оскільки забезпечує високий рівень безпеки.

• Implicit Flow: коли потрібна швидкість

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

Раніше Implicit Flow нерідко використовували у веб-додатках SPA, але наразі цей потік вважається застарілим. Сьогодні його майже витіснив PKCE (Proof Key for Code Exchange), який додає безпековий шар до Authorization Code Flow. Давайте їх порівняємо: 

• Client Credentials Flow: доступ без участі користувача

Це специфічний потік, призначений для машинної взаємодії – без прямої участі користувача.  Клієнт (наприклад, серверний додаток) аутентифікується за допомогою Client ID та Client Secret – API авторизація через токен доступу здійснюється автоматично.

Client Credentials Flow – простий та безпечний метод для взаємодії “сервер-сервер”, він часто використовується для внутрішніх сервісів бізнесу. Наприклад, коли CRM-система запитує дані з корпоративного сервера, то отримує доступ до API через токен.

• Resource Owner Password Credentials Flow

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

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

Що таке токен доступу (Access Token)

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

Токени доступу можуть мати різні формати, але найпопулярнішим є JWT (JSON Web Token). Він складається з трьох частин:

• Заголовок (Header): містить інформацію про тип токена та алгоритм підпису.

• Корисне навантаження (Payload): тут зберігається інформація про користувача та дозволи (наприклад, ім'я користувача та термін дії токена).

• Підпис (Signature): забезпечує цілісність і правдивість токена.

 Така структура дозволяє серверам ресурсів швидко перевіряти дійсність токена без додаткових запитів до сервера авторизації.

Токен доступу видається сервером авторизації після успішної аутентифікації користувача та його згоди надати доступ. В рамках Authorization Code Flow, наприклад, клієнт обмінює код авторизації на токен через захищений запит. У Implicit Flow токен повертається одразу через URL. Видача відбувається після перевірки Client ID і, за потреби, Client Secret.

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

Саме тому клієнтські додатки повинні мають зберігати токен у безпечному місці. Для веб-додатків це зазвичай не Local Storage, який є вразливим до XSS-атак, а HttpOnly cookie або спеціалізовані сховища, що гарантують захист.

В OAuth використовується два різновиди токенів: для доступу і для оновлення. Головна відмінність між access token і refresh token продиктована їхнім призначенням. 

• Access Token — це короткочасний ключ. Він використовується для безпосереднього доступу до ресурсів і має невеликий термін дії.

• Refresh Token — це довготривалий ключ, призначений для отримання нового Access Token без необхідності повторного вводу логіна та пароля. Це дозволяє додатку підтримувати сесію користувача протягом тривалого часу, при цьому забезпечуючи безпеку. 

Як працює авторизація через токени

Наразі токени – найкращий спосіб авторизації в додатку, що прийшов на зміну застарілим механізмам із сесіями та файлами cookie. Давайте зупинимось на тому, як токен передається, захищається та перевіряється.

У найпростішому вигляді покроковий процес отримання токена OAuth виглядає так: 

1. Запит на авторизацію: Користувач заходить у додаток-клієнт і ініціює вхід (наприклад, через Google).
2. Надання згоди: Користувач перенаправляється на сервер авторизації, підтверджує свою особу та надає згоду на доступ.
3. Видача токена: Сервер авторизації видає токен доступу і відправляє його клієнтському додатку. 

Як токен передається між клієнтом і сервером? Коли клієнтському додатку потрібно отримати доступ до даних (наприклад, завантажити фотографії або отримати список друзів), він відправляє запит до сервера ресурсів. Токен зазвичай передається у заголовку HTTP-запиту:

Authorization: Bearer <access_token>

Цей спосіб передачі є стандартом. Слово Bearer вказує, що доступ надається тому, хто володіє цим токеном.

Чи несе передача токена ризики кібербезпеки? В OAuth 2.0 передбачені усі необхідні перестороги, аби мінімізувати загрозу перехоплення. Для захисту токена використовується HTTPS, яке шифрує дані під час передачі. Токени зберігаються в безпечних сховищах (наприклад, Keychain на iOS або зашифрованих базах). Обмежений строк дії токена також знижує ризики при витоку. 

Як перевірити access token? Кожного разу,  коли додаток звертається з токеном до сервера ресурсів, останній проводить низку перевірок: 

1. Перевірка формату. Сервер підтверджує, що токен відповідає цільовому стандарту (наприклад, JWT);
2. Перевірка підпису. Якщо йдеться про JWT-токен, сервер перевіряє цифровий підпис, щоб гарантувати його цілісність;
3. Перевірка строку дії. Сервер відхиляє токен, якщо його термін дії минув;
4. Перевірка дозволів. Сервер перевіряє, чи дозволяє даний токен доступ до запитуваних ресурсів.

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

Безпека в OAuth 2.0

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

• Перехоплення коду авторизації. Під час обміну авторизаційного коду на токен зловмисники можуть перехопити даний код. Для public-клієнтів (наприклад, мобільних додатків) це може бути серйозною проблемою. 

  • Як уникнути загрози: Використовуйте розширення PKCE (Proof Key for Code Exchange). Воно додає додатковий секретний ключ, який робить перехоплений код марним для зловмисника.

• Витік токена доступу. Якщо токен потрапляє в чужі руки, зловмисник може встигнути отримати несанкціонований доступ до даних. 

  • Як уникнути загрози: Зберігайте токени лише у захищених місцях (наприклад, HttpOnly cookie, а не Local Storage). Використовуйте Keychain (iOS) або Keystore (Android) для мобільних додатків.

• Міжсайтова підробка запиту (CSRF). Зловмисник може змусити користувача ініціювати запит на авторизацію, щоб отримати доступ до його облікового запису та вчинити від його імені ті чи інші дії.

  • Як уникнути загрози: Використовуйте параметр state у запиті на авторизацію. Це унікальний, тимчасовий ідентифікатор, який дозволяє переконатися, що відповідь надходить саме від ініційованого користувачем запиту.

Визначальне значення для безпеки OAuth 2.0 відіграє протокол HTTPS. Весь трафік, пов'язаний з авторизацією, має бути зашифрований за допомогою HTTPS/SSL. Це стосується не лише сторінок входу, а й усіх API-запитів, де передаються токени. Нешифрований трафік може бути легко перехоплений, а зловмисник отримає доступ до всіх даних, включно з токенами. 

Що ще можна зробити для безпеки OAuth 2.0? Наступні рекомендації зі зберігання та оновлення токена ніколи не будуть зайвими: 

• Використовуйте Refresh Token для оновлення Access Token, зберігаючи його лише на сервері.

• Встановлюйте короткий строк дії для Access Token (наприклад, не більше як година) і регулярно оновлюйте його через Refresh Token.

Приклади застосування OAuth 2.0

Сьогодні важко знайти онлайн-сервіс чи додаток, де не використовується OAuth2. Приклад його реалізації зустріне вас на будь-якому сайті, в будь-якому онлайн-магазині, на будь-якій диджитал-платформі. Сервіс авторизації через токен став повсюдним – ми несвідомо користуємося ним буквально щодня. 

Найочевидніший приклад застосування OAuth 2.0 — можливість увійти до сервісу за допомогою акаунтів великих платформ. Коли ви натискаєте кнопку “Увійти через Google” або “Увійти через Facebook”, саме протокол OAuth 2.0 забезпечує видачу токенів, які підтверджують вашу особу та дозволяють сервісу отримати лише необхідні дані (наприклад, email чи ім’я). Інтеграція OAuth2 з Google, Facebook та Twitter/X спростила життя мільйонів користувачів; вона також допомагає бізнесам будувати безшовний користувацький досвід у диджиталі. 

 У веб-додатках будь-якого призначення OAuth 2.0 часто використовується для надання доступу до сторонніх API без передачі пароля користувача. Наприклад, Наприклад, SaaS-платформа для управління проєктами може інтегруватись так з Google Drive, щоб користувачі могли прикріплювати файли. Безпечна авторизація API сьогодні реалізується через потік Authorization Code Flow з PKCE. 

Застосування OAuth2 для мобільних застосунків також стало базовим стандартом, оскільки забезпечує безшовну та безпечну аутентифікацію. Наприклад, додаток для фітнесу може використовувати Facebook Login для доступу до профілю користувача. Authorization Code Flow із PKCE застосовується для безпеки, а токени зберігаються в Keychain (iOS) або Keystore (Android). Refresh Token дозволяє оновлювати доступ без повторного входу, покращуючи користувацький досвід.

Висновки

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

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

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

Для створення таких рішень необхідна досвідчена команда розробників з реальними успішними кейсами. Якщо вашому бізнесу потрібна практична інструкція з впровадження OAuth2 – не баріться, звертайтеся по консультацію до WEZOM просто зараз. Наші фахівці мають величезний досвід налаштування Oauth2 для API під різноманітні продукти: десктопний софт, сайти, SPA, мобільні додатки тощо. Ми з радістю вивчимо ваш запит та підкажемо практичні рішення. 

FAQ