Що таке OAuth2: основні концепції

Прийшов час розглянути одну з найважливіших тем — забезпечення безпеки наших вебзастосунків. У цьому блоці будемо говорити про аутентифікацію й авторизацію, починаючи з протоколу OAuth2.

Давайте почнемо з постановки проблеми. Уявіть, що ви хочете протестувати стороннє API, яке вимагає ваших даних (наприклад, доступ до профілю в Google). Ви, звісно, не хочете роздавати свої дані на всі боки. Ось тут на сцену виходить OAuth2 — протокол, який дозволяє надавати стороннім застосункам доступ до ваших даних без потреби ділитися паролем. Зручно? Ще б!

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

Аутентифікація й авторизація: у чому різниця?

Перш ніж рухатись далі, варто пригадати, що аутентифікація й авторизація — це не те саме.

• Аутентифікація (authentication) — процес підтвердження особи користувача (наприклад, «Ви справді [ваше ім'я користувача]?»).
• Авторизація (authorization) — процес визначення, що користувач може робити («Ви дійсно можете переглядати цю сторінку або звертатися до цього API?»).

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

Компоненти OAuth2

OAuth2 — це як вистава, у якій у кожного учасника своя роль. Ось основні «актори»:

1. Клієнт (Client):
   це застосунок, який хоче отримати доступ до ресурсів користувача. Наприклад, ваш улюблений мобільний клієнт для роботи з календарем.
2. Сервер авторизації (Authorization Server):
   це сервер, який обробляє запити на авторизацію. Він перевіряє, чи може клієнт отримати доступ, і, якщо все гаразд, видає токени.
3. Ресурсний сервер (Resource Server):
   сервер, який володіє даними, до яких клієнт хоче отримати доступ. Наприклад, сервер з вашим профілем у Google.
4. Власник ресурсу (Resource Owner):
   це користувач, який володіє даними. Наприклад, це ви, коли даєте дозволи застосунку працювати з вашим профілем.

Процес взаємодії

Взаємодію між учасниками можна уявити як танець, що складається з кількох кроків:

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

Типи grant-ів: як клієнти "випрошують" доступ?

"Grant" — це механізм, який описує, як клієнт отримує токен. Ось найпопулярніші типи grant-ів:

1. Authorization Code Grant (авторизаційний код):
   використовується для серверних застосунків. Клієнт перенаправляє користувача на сервер авторизації, де той вводить свої дані, а потім сервер повертає клієнту спеціальний код, який можна обміняти на токен.
   Як приклад — авторизація через Google OAuth.
2. Implicit Grant:
   більш спрощений варіант для клієнтських застосунків, де токен видається напряму. Однак цей метод вважається застарілим і небезпечним, оскільки токен може бути перехоплений в URL.
3. Resource Owner Password Credentials Grant:
   клієнт безпосередньо приймає ім'я користувача та пароль, щоб отримати доступ. Використовується рідко, бо потрібно вводити пароль сторонньому застосунку. Підходить тільки для довірених застосунків.
4. Client Credentials Grant:
   використовується для авторизації серверів без участі користувача. Наприклад, один мікросервіс авторизується перед іншим або для доступу до даних, що належать самому застосунку, а не конкретному користувачеві.

Приклади використання OAuth2

Google активно використовує OAuth2. Наприклад, коли ви хочете підключити сторонній застосунок до свого Google-акаунту, процес виглядає так:

1. Виводиться сторінка авторизації Google (доступна тільки через HTTPS, щоб дані були в безпеці).
2. Після успішного входу користувач підтверджує доступи (наприклад, до Google Drive).
3. Застосунок отримує токен і використовує його для роботи з API Google.

А взагалі — подумайте про всі кнопки «Увійти за допомогою...», які ви бачили (наприклад, «Увійти за допомогою Facebook»). Ці кнопки — реальне застосування OAuth2.

Якщо говорити про FastAPI, то вбудована підтримка OAuth2 дозволяє легко інтегрувати цей механізм у ваш API. Ми ще налаштуємо таку авторизацію в наступній лекції! Спойлер: буде цікаво.

Переваги OAuth2

Чому ж OAuth2 став таким популярним?

• Мінімізація ризику витоку пароля:
  клієнти не бачать і не зберігають пароль користувача, вони працюють лише з токенами.
• Гнучкість доступу:
  можна налаштувати доступ на рівні «що можна», «що не можна». Наприклад, клієнт отримує дозвіл тільки на читання даних, але не на їх запис.
• Єдиний вхід (Single Sign-On):
  користувач може використовувати один обліковий запис для авторизації в різних системах.
• Широке застосування:
  підтримується більшістю великих сервісів (Google, Facebook, GitHub тощо).

Підсумок

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

Просто подумайте: щоразу, коли ви використовуєте «Увійти за допомогою Google» або «Увійти через Facebook», ви вже взаємодієте з OAuth2. А тепер уявіть, що ви зможете впровадити це у власний застосунок. Це як стати магом, який керує доступом, тільки замість чарівної палички — код на Python!