Зачем нужен OAuth

До OAuth системы решали проблему интеграции просто: сервис A просил пользователя ввести логин и пароль от сервиса B, сохранял их и использовал для доступа. Это небезопасно по нескольким причинам:
— Пароль хранится на чужом сервере.
— Доступ «всё или ничего» — нельзя ограничить права.
— Отозвать доступ можно только сменив пароль — для всех сервисов сразу.

OAuth 2.0 решает это через делегирование: сервис A получает ограниченный токен доступа к конкретным ресурсам сервиса B, без знания пароля пользователя.

Основные флоу OAuth 2.0

Authorization Code — самый безопасный флоу для веб-приложений с пользователем в петле:

1. Клиент → Сервер авторизации: запрос кода (+ state, redirect_uri)
2. Сервер авторизации → Пользователь: форма согласия
3. Пользователь → Сервер авторизации: разрешает
4. Сервер авторизации → Клиент: authorization code
5. Клиент → Сервер авторизации: code → access token + refresh token
6. Клиент → API: Bearer access_token

Client Credentials — для machine-to-machine без пользователя. Платформа персонализации аутентифицируется в CRM через client_id + client_secret, получает token. Никакого пользователя в процессе нет.

POST /token
  grant_type=client_credentials
  &client_id=gf_platform
  &client_secret=*****
  &scope=catalog:read orders:read

→ { access_token: "eyJ...", expires_in: 3600 }

OAuth в e-commerce интеграциях

Типичные сценарии, где OAuth используется при подключении платформы персонализации:

Интеграция Флоу Зачем
Подключение к CMS (Shopify, WooCommerce) Authorization Code Доступ к каталогу и заказам от имени магазина
API платформы персонализации Client Credentials Сервер CMS получает рекомендации
Подключение CRM Client Credentials Экспорт сегментов аудитории
Аналитика третьей стороны Authorization Code Чтение данных GA4 или другой системы

Совет: При выборе scope запрашивайте минимально необходимые права. Если платформа персонализации нужна только для чтения каталога — не запрашивайте scope на запись заказов. Это уменьшает риски при компрометации токена.

Типичные ошибки реализации

  • Не проверять state параметр при Authorization Code флоу → уязвимость к CSRF.
  • Хранить refresh token в localStorage → уязвимость к XSS, используйте HttpOnly cookie.
  • Не обновлять access token по истечении и молча падать с 401 → пользователь видит ошибку вместо переавторизации.
  • Бесконечный срок жизни токена — access token с TTL «навсегда» нивелирует главное преимущество OAuth.