Опишіть своїми словами, як працює OAuth v2.

Повне пояснення

Що це і навіщо OAuth v2 (Open Authorization) – протокол, що розділяє ролі: ресурсний власник (користувач), клієнт (застосунок) і авторизаційний сервер. Він дозволяє клієнту отримати доступ до API без розкриття пароля, зберігаючи при цьому контроль над обсягом доступу.

Ключові принципи/терміни

• Authorization Code Grant – найпоширеніший flow, що передає короткоживучий код, який клієнт обмінює на access‑token.
• Implicit Grant – використовується в SPA, де токен повертається безпосередньо у URL‑fragment.
• Client Credentials Grant – для сервер–на‑сервер, коли клієнт представляє себе.
• Refresh Token – довготривалий токен, що дозволяє отримати новий access‑token без повторної авторизації.
• Scopes – обмеження доступу, що визначають, які ресурси клієнт може читати/змінювати.

Як це працює (логіка)

1. Клієнт перенаправляє користувача на URL авторизаційного сервера з параметрами client_id, redirect_uri, scope.
2. Користувач вводить облікові дані і погоджується на доступ.
3. Сервер повертає authorization code (або токен у випадку Implicit) на redirect_uri.
4. Клієнт обмінює код на access‑token, надсилаючи client_secret (у випадку Confidential Client).
5. Клієнт додає access‑token у заголовок Authorization: Bearer <token> при запитах до API.
6. Якщо токен закінчився, клієнт використовує refresh‑token для отримання нового access‑token.

Практика і реалізація (Node.js / TypeScript)

import { AuthorizationCode } from 'simple-oauth2';
const client = new AuthorizationCode({
  client: { id, secret },
  auth: { tokenHost, authorizePath, tokenPath }
});
const authorizationUri = client.authorizeURL({ redirect_uri, scope });
// після отримання коду
const tokenParams = { code, redirect_uri };
const accessToken = await client.getToken(tokenParams);

Тестування

• Unit: мокати HTTP‑запити до авторизаційного сервера, перевіряти правильність формування URL.
• Integration: використовувати supertest для перевірки реального потоку авторизації.
• E2E: Playwright для симуляції логіну користувача і отримання токену.

Безпека

• Зберігати client_secret у перемінних середовища, не в коді.
• Використовувати HTTPS для всіх запитів.
• Перевіряти state параметр, щоб уникнути CSRF.
• Обмежувати scope до мінімально необхідного.

Особливості в контексті Backend (NestJS, Express)

• У NestJS можна скористатися @nestjs/passport і passport-oauth2 для інтеграції.
• У Express – middleware express-oauth-server або oauth2orize.

Оптимізація та edge cases

• Токени мають короткий термін дії (наприклад, 1 година) для зменшення ризику компрометації.
• Refresh‑token має бути одноразовим (rotate) – після використання генерується новий.
• Обробляти помилки 401/403, автоматично виконуючи refresh‑token.

Часті помилки

1. Неправильний redirect_uri → 400 Bad Request.
2. Відсутність state → CSRF‑уразливість.
3. Перевищення scope → 403 Forbidden.
4. Використання client_secret у SPA → компрометація.
5. Неправильний формат токену (наприклад, Bearer token) → 401.
6. Необроблені помилки при refresh‑token → нескінченний цикл.
7. Зберігання токену у localStorage → XSS‑ризик.
8. Необмежений lifetime access‑token → ризик довготривалого доступу.

Cheatsheet

• Authorization: Bearer <access_token> – заголовок.
• scope – список дозволів, розділених пробілом.
• expires_in – час у секундах до закінчення дії токену.
• refresh_token – використовується лише у Confidential Client.

Follow‑up питання

• Як реалізувати refresh‑token у SPA без client_secret?
• Які ризики пов’язані з використанням Implicit Grant у сучасних браузерах?
• Як забезпечити безпечне зберігання токену у мобільному застосунку?