Протокол OAuth
OAuth vs OAuth 2.0 — в чём разница
| OAuth 1.0 | OAuth 2.0 | |
|---|---|---|
| Год | 2007 | 2012 |
| Подписи (signatures) | Да, обязательны (HMAC, RSA) | Нет, токены обычные (Bearer) |
| Обмен токенами | Сложный (многоступенчатый) | Гибкий и модульный |
| Поддержка клиентов | Только с сервером | Есть client_credentials, password, authorization_code, implicit, refresh_token, PKCE |
| Безопасность | Более безопасен на уровне протокола, но сложен | Безопасность зависит от реализации |
| Стандарты | Много ручной работы | Стал де-факто стандартом |
OAuth 2.0 — это полностью переработанная, более гибкая, но менее строгая по протоколу версия.
Как работает OAuth 2.0 (упрощённо)
Цель
Позволить стороннему приложению (например, Zapier) получить доступ к твоему API от имени пользователя или от имени сервиса, без передачи логина/пароля.
Потоки авторизации в OAuth2 (flows)
1. Authorization Code Flow (с пользователем)
Самый распространённый для UI-приложений.
- Пользователь перенаправляется на страницу авторизации (
/oauth/authorize) - Вводит логин/пароль
- Приложение получает authorization code
- Меняет его на access_token
- Использует
Authorization: Bearer abc123в запросах к API
2. Client Credentials Flow (без пользователя)
Идеально для машинных интеграций (например, Zapier).
- Запрос с
client_id+client_secret - Получаешь
access_token - Используешь его при вызове API
Как выглядит запрос с OAuth2 токеном
GET /api/v4/listings
Authorization: Bearer abc123
Главное отличие от Basic/Auth Key
| Basic Auth | OAuth 2.0 | |
|---|---|---|
| Где хранятся ключи | У клиента | У сервера, клиент получает временный токен |
| Возможность отозвать | Нет | Да (revoke token) |
| Время жизни | Бессрочно (обычно) | Ограничено + есть refresh_token |
| Может быть от имени пользователя | Нет | Да (resource owner) |
| Поддержка разных уровней доступа (scopes) | Нет | Да |
OAuth2 — это стандарт для "разреши другому приложению временно и безопасно использовать мой API". Без передачи логина и пароля, с контролем доступа.
Сравнительная таблица способов аутентификации
| Способ | Уровень безопасности | Поддержка в Zapier | Лёгкость внедрения | Масштабируемость | Современность | Комментарий |
|---|---|---|---|---|---|---|
| Basic Auth | 🟡 Низкий (если без HTTPS) | ✅ Да | ✅ Очень просто | 🔴 Плохо (учётки не масштабируются) | 🔴 Устаревает | Хорош для начальных тестов, но не рекомендуется в прод |
| API Key (в заголовке) | 🟡 Средний | ✅ Да | ✅ Просто | 🟡 Ограничено (трудно управлять правами) | 🟡 Терпимо | Подходит для сервер-сервер взаимодействия |
| OAuth2 (Doorkeeper) | 🟢 Высокий | ✅ Да (родная поддержка) | 🔴 Сложнее | 🟢 Отлично масштабируется | 🟢 Стандарт де-факто | Рекомендуется для любых публичных/внешних API |
| JWT (сами по себе) | 🟢 Высокий | 🔴 Нет нативной поддержки | 🟡 Средне | 🟢 Да | 🟡 Модно, но надо реализовывать вручную | Используется во внутренних API, требует контроля |
| Session + Cookie | 🔴 Плохо для API | 🔴 Нет | 🔴 Только для браузеров | 🔴 Не масштабируется | 🔴 Не используется в API | Не подходит для Zapier и REST API |