OAuth 2.0

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

Актори

Чотири ролі в потоці OAuth:

• Власник ресурсу — ви, користувач із десь даними
• Клієнт — програма, яка потребує доступу (наприклад, сторонній засіб перегляду календаря)
• Сервер авторизації — служба, яка автентифікує вас і видає маркери (наприклад, кінцева точка Google OAuth)
• Сервер ресурсів — API, що зберігає ваші дані (наприклад, Google Calendar API)

Потік коду авторизації

Стандартний потік на стороні сервера, спрощений:

1. Ви натискаєте «Підключити Google Календар» у клієнтській програмі.
2. Клієнт перенаправляє ваш браузер на сервер авторизації Google із параметрами: client_id, redirect_uri, область дії (calendar.read), стан (токен CSRF).
3. Ви автентифікуєтеся в Google, якщо ще не ввійшли в систему.
4. Google показує вам екран згоди: «CalendarViewer хоче прочитати ваш календар. Дозволити?»
5. Ви клацаєте «Дозволити». Google перенаправляє ваш веб-переглядач назад до redirect_uri клієнта з одноразовим кодом авторизації.
6. Серверний код клієнта обмінює код авторизації (а також його секрет клієнта) на маркер доступу, викликаючи напряму кінцеву точку маркера Google.
7. Клієнт використовує маркер доступу для виклику Google Calendar API від вашого імені.
8. Коли термін дії маркера доступу закінчується (зазвичай через годину), клієнт використовує маркер оновлення, щоб отримати новий, не турбуючи вас.

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

OAuth 2.0 проти OAuth 2.1 проти OIDC

• OAuth 2.0 — це стандарт 2012 року (RFC 6749). З тих пір було додано кілька RFC розширень і документів із передовими методами.
• OAuth 2.1 (у чернетці станом на 2026 рік) об’єднує поточні передові практики в єдину специфікацію — обов’язковий PKCE, вилучено Implicit Flow тощо.
• OpenID Connect (OIDC) — це рівень ідентичності на основі OAuth 2.0. Лише OAuth дає непрозорий маркер доступу; OIDC додає маркер ідентифікатора (JWT), який автентифікує користувача. Більшість кнопок «Увійти за допомогою…» використовують OIDC, а не звичайний OAuth.

Типи надання

OAuth 2.0 визначає кілька потоків для різних сценаріїв:

• Код авторизації — стандартний потік на стороні сервера, описаний вище. З розширенням PKCE також використовується мобільними додатками та програмами SPA.
• Implicit Flow (застаріле) — маркери доступу видаються безпосередньо через фрагмент URL-адреси. Вразливість до витоку токенів; замінено на Код авторизації + PKCE.
• Облікові дані власника ресурсу Пароль (використовується рідко) — клієнт збирає пароль користувача та обмінює його на маркер. Слід використовувати лише в сценаріях міграції застарілих версій.
• Облікові дані клієнта — для міжмашинного зв’язку, де немає користувача. Клієнт аутентифікується та отримує токен для власних ресурсів.
• Код пристрою — для пристроїв без браузерів (телевізори, IoT). Пристрій показує код; користувач авторизується з телефону або ноутбука.
• Refresh Token — обмінює довготривалий маркер оновлення на новий маркер доступу без взаємодії з користувачем.

PKCE: обов’язкове розширення

PKCE (ключ доказу для обміну кодами, вимовляється як «піксі») запобігає атакам перехоплення коду авторизації. Клієнт генерує випадковий секрет, хешує його та надсилає хеш у запиті авторизації. Під час обміну кодом він надсилає оригінальний секрет. Сервер авторизації перевіряє відповідність хешу. Будь-який зловмисник, який перехоплює код, не може обміняти його без вихідного секрету.

PKCE тепер вважається обов’язковим для всіх клієнтів OAuth — як публічних (браузер, мобільний), так і конфіденційних (на стороні сервера).

Scopes

Tokens випускаються з певними областями — діями, які їм дозволено виконувати. Типові області дії Google виглядають так: https://www.googleapis.com/auth/calendar.readonly. Клієнт запитує обсяги; користувач бачить їх на екрані згоди та схвалює або відмовляє. Принцип найменших привілеїв: запитуйте лише ті області, які вам дійсно потрібні.

Поширені атаки OAuth

• Відкрите перенаправлення. Неправильно налаштований параметр redirect_uri дозволяє зловмиснику перенаправляти код авторизації на власний сервер.
• Параметр State omission. Без значення стану, прив’язаного до сеансу користувача, потоки OAuth вразливі до CSRF — зловмисник обманом змушує жертву завершити потік OAuth, який пов’язує обліковий запис зловмисника з сеансом жертви.
• Витік токенів в історії браузера (основний неявний потік слабкість).
• Крадіжка токенів через XSS. Якщо клієнтська програма зберігає токени в localStorage та має будь-яку вразливість XSS, зловмисники можуть їх викрасти.
• Фішинг екрана згоди. Зловмисник реєструє зловмисного клієнта OAuth, який запитує конфіденційні області; користувач, якому потрібно натиснути «Дозволити» на екранах згоди, надає доступ без перевірки.

Що робити як користувач

• Періодично переглядайте підключені програми в налаштуваннях облікового запису Google/Apple/Microsoft/Facebook/GitHub. Відкликайте ті, якими ви не користуєтеся.
• Перш ніж надавати доступ, ознайомтеся з областями екрана згоди. «Керувати своїм календарем» відрізняється від «Переглядати свій календар».
• Скептично ставтеся до запитів OAuth від програм, які ви не впізнаєте, навіть якщо вони з’являються під час знайомого робочого процесу.