OAuth 2.0
OAuth 2.0 — это протокол авторизации, который позволяет приложениям получать доступ к данным пользователя без передачи его логина и пароля. Простыми словами: когда вы нажимаете «Войти через Google», «Войти через VK» или подключаете CRM к API банка — работает OAuth 2.0 авторизация.
Что такое OAuth? Это стандарт безопасного делегирования доступа через access token и refresh token. OAuth используется в REST API, мобильных приложениях, интеграциях CRM, ERP, маркетинговых платформ, банковских сервисов и корпоративных систем.
В статье разберём:
- ✅ как работает OAuth 2.0
- ✅ что такое access token и refresh token
- ✅ OAuth API и REST API
- ✅ OAuth в интеграциях
- ✅ OAuth vs OpenID Connect vs SAML
- ✅ схемы авторизации и grant types
- ✅ ошибки внедрения OAuth 2.0
- ✅ безопасность OAuth авторизации
📑 Содержание
- Что такое OAuth 2.0 простыми словами
- OAuth — это авторизация или аутентификация?
- Основные роли в OAuth 2.0
- Как работает OAuth 2.0 — схема по шагам
- OAuth токены: access token и refresh token
- Grant Types (типы OAuth потоков)
- OAuth 2.0 для REST API и интеграций
- Что такое scopes в OAuth
- JWT в OAuth 2.0
- OAuth vs OpenID Connect vs SAML
- Безопасность OAuth 2.0
- Частые ошибки OAuth
- Популярные OAuth-провайдеры
- Примеры OAuth интеграций
- FAQ по OAuth 2.0
- Выводы
Что такое OAuth 2.0 простыми словами
OAuth 2.0 — это открытый протокол авторизации, который позволяет стороннему приложению (клиенту) получить ограниченный доступ к данным пользователя (владельца ресурса) на другом сервере без передачи его пароля.
Классический пример — кнопка «Войти через Google» на любом сайте.
Главная идея OAuth — пользователь не сообщает пароль стороннему приложению. Вместо этого сервис выдаёт приложению специальный токен доступа.
Например:
- сайт получает доступ к вашему email через Google;
- CRM подключается к Telegram API;
- маркетинговая система читает данные из Google Analytics;
- ERP получает доступ к API банка.
OAuth простыми словами: вы даёте не ключ от квартиры, а временный пропуск только в одну комнату и только на ограниченное время.
Где используется OAuth 2.0: реальные сценарии
OAuth 2.0 применяется везде, где нужно дать одному сервису доступ к данным другого без пароля. От авторизации через соцсети до банковских API и интеграций CRM с маркетинговыми платформами.
| Сценарий | Как используется OAuth | Пример |
|---|---|---|
| Авторизация через Google или соцсети (ВКонтакте, Apple, Mail.ru) | Сайт получает email, имя и аватар пользователя без его пароля. Пользователь нажимает «Войти через ...», даёт разрешение — и сайт запоминает его. | Приложение для заметок предлагает «Войти через Google» — не нужно заводить новый пароль. |
| REST API (защита бэкенда) | Клиент (веб, мобильное приложение) отправляет access token в заголовке Authorization: Bearer <token>. Сервер проверяет токен и возвращает данные. | API интернет-магазина, которое возвращает заказы только после предъявления валидного токена. |
| Мобильные приложения (iOS, Android) | Используют Authorization Code Flow with PKCE — безопасный поток для публичных клиентов без client_secret. | Приложение банка, которое после логина через OAuth получает доступ к API счетов пользователя. |
| CRM и ERP (интеграции) | CRM получает доступ к данным внешних сервисов (почта, календари, файлы, маркетинговые платформы) через OAuth-токены. | ELMA365 через OAuth подключается к Google Sheets для выгрузки отчётов или к RetailCRM для синхронизации заказов. |
| Банковские API (Open Banking) | Сервис по управлению личными финансами запрашивает у банка access token для чтения баланса и истории операций. Пользователь соглашается через интерфейс банка. | Приложение «Учет расходов» подключается к API Тинькофф или Сбера через OAuth, получает список транзакций. |
| Умные дома и IoT | Приложение получает токен для управления устройствами через API производителя. | Приложение «Яндекс Дом» через OAuth получает доступ к управлению колонкой или лампочкой. |
Благодаря OAuth 2.0 пользователь не плодит десятки паролей, а разработчики не вынуждены хранить чужие учётные данные.
OAuth — это авторизация или аутентификация?
OAuth 2.0 — это протокол авторизации, а не аутентификации.
| Процесс | Что означает |
|---|---|
| Аутентификация | Проверка личности — «кто вы?» |
| Авторизация | Проверка прав — «что вам разрешено?» |
OAuth отвечает именно за выдачу разрешений на доступ к данным.
Если нужно определить личность пользователя — поверх OAuth используют OpenID Connect (OIDC).
❗ Частая ошибка в интернете — фраза «OAuth аутентификация». Технически это неверно. OAuth — это именно авторизация.
Основные роли в OAuth 2.0
В OAuth 2.0 участвуют 4 основные стороны: пользователь, клиент, сервер авторизации и сервер ресурсов.
| Роль (англ.) | Роль (рус.) | Описание |
|---|---|---|
| Resource Owner | Владелец ресурса | Пользователь, который даёт разрешение на доступ к своим данным. |
| Client | Клиент | Приложение (веб-сайт, мобильное приложение), которое запрашивает доступ. |
| Authorization Server | Сервер авторизации | Выдаёт токены после проверки логина и согласия пользователя. |
| Resource Server | Сервер ресурсов | Хранит данные пользователя (например, API Google), проверяет токены и возвращает данные. |
Иногда сервер авторизации и сервер ресурсов — это один и тот же сервис (например, у Google).
Как работает OAuth 2.0 — схема взаимодействия по шагам
OAuth 2.0 работает через обмен временными токенами. Пользователь проходит авторизацию на доверенном сервере, а приложение получает ограниченный доступ к API.
Пошаговая схема OAuth 2.0
| Шаг | Что происходит | Участники |
|---|---|---|
| 1 | Пользователь нажимает «Войти через Google» на сайте | User → Client |
| 2 | Приложение перенаправляет пользователя на Authorization Server | Client → Authorization Server |
| 3 | Пользователь вводит логин и пароль | User → Authorization Server |
| 4 | Пользователь подтверждает разрешения (scopes) | User → Authorization Server |
| 5 | Сервер авторизации выдаёт временный авторизационный код (authorization code) и перенаправляет обратно | Authorization Server → Client |
| 6 | Клиент меняет code на access token | Client → Authorization Server |
| 7 | Сервер авторизации возвращает access token (и refresh token). | Authorization Server → Client |
| 8 | Приложение отправляет access token в API | Client → Resource Server |
| 9 | API проверяет токен и возвращает данные | Resource Server → Client |
Authorization Code Flow
Самый популярный и безопасный сценарий OAuth — Authorization Code Flow.
Именно он используется в:
- Google OAuth;
- VK OAuth;
- GitHub OAuth;
- корпоративных API;
- банковских интеграциях.
OAuth токены: access token и refresh token
OAuth использует токены вместо логинов и паролей. Основные типы — access token и refresh token.
| Токен | Назначение | Время жизни | Риски |
|---|---|---|---|
| Access Token | Доступ к API | Минуты или часы | Если украдут — злоумышленник сможет делать запросы до истечения срока. |
| Refresh Token | Получение нового access token | Дни или месяцы | Если украдут — злоумышленник сможет получать новые access token долгое время. |
Что такое OAuth access token
OAuth access token — это временный ключ доступа к API (Действует несколько минут — несколько часов).
Он передаётся в HTTP-заголовке:
Authorization: Bearer ACCESS_TOKEN
Что такое OAuth refresh token
OAuth refresh token — долгоживущий ключ (дни/месяцы) для получения нового access token без повторного входа пользователя.
Это позволяет пользователю не вводить пароль каждый час.
Grant Types (типы разрешений OAuth потоков) — когда какой использовать
OAuth 2.0 определяет несколько сценариев (grants) для разных типов приложений. Выбор зависит от того, веб-это приложение, мобильное, SPA или сервис-ту-сервис.
| Grant Type (Тип потока) | Для чего используется | Рекомендация |
|---|---|---|
| Authorization Code Flow | Веб-приложения с серверной частью | ✅ Основной безопасный вариант. Использует авторизационный код и client_secret. |
| Authorization Code + PKCE | SPA и мобильные приложения | ✅ Рекомендуемый стандарт для публичных клиентов. Защищает от перехвата кода. |
| Client Credentials | Сервис-ту-сервис (без пользователя) | ✅ Для backend интеграций. Не требует участия пользователя. |
| Implicit Flow | Старые SPA | ❌ Устарел. Не используйте — небезопасен. |
| Password Grant | Легаси системы. Доверенные приложения | ❌ Не рекомендуется. Пользователь передаёт пароль напрямую клиенту |
Почему PKCE обязателен
PKCE защищает OAuth от перехвата authorization code и считается обязательным стандартом для мобильных и SPA-приложений.
OAuth 2.0 для REST API и интеграций
OAuth 2.0 — основной стандарт защиты REST API. Клиент добавляет access token в HTTP-заголовок Authorization: Bearer <token>, сервер ресурсов проверяет токен и возвращает данные.
Пример OAuth запроса к API
curl -X GET https://api.example.com/profile \ -H "Authorization: Bearer ACCESS_TOKEN"
Пример получения токена
curl -X POST https://auth.example.com/token \ -d "grant_type=authorization_code" \ -d "client_id=CLIENT_ID" \ -d "client_secret=CLIENT_SECRET" \ -d "code=AUTH_CODE"
OAuth в API интеграциях
| Интеграция | Как используется OAuth |
|---|---|
| CRM ↔ Google Sheets | Доступ к таблицам через API |
| ERP ↔ банк | Получение данных о платежах |
| Маркетинг ↔ соцсети | Публикация контента |
| BI ↔ аналитика | Получение статистики |
Что такое scopes в OAuth
Scopes — это ограничения доступа, которые определяют, какие действия разрешены приложению.
Примеры scopes:
| Scope | Разрешение |
|---|---|
| Чтение email пользователя | |
| profile | Доступ к профилю |
| read_orders | Чтение заказов |
| write_posts | Создание публикаций |
JWT в OAuth 2.0
Во многих OAuth системах access token реализован в формате JWT (JSON Web Token).
JWT содержит:
- идентификатор пользователя;
- время жизни токена;
- scopes;
- цифровую подпись.
Структура JWT
| Часть JWT | Что содержит |
|---|---|
| Header | Алгоритм подписи |
| Payload | Данные пользователя и claims |
| Signature | Цифровая подпись |
OAuth vs OpenID Connect vs SAML
OAuth, OpenID Connect и SAML решают разные задачи и часто используются вместе. OAuth 2.0 — для авторизации (доступ к данным). SAML — для корпоративного SSO. OpenID Connect — надстройка над OAuth 2.0 для аутентификации (узнать, кто пользователь).
| Технология | Основная задача | Где применяется |
|---|---|---|
| OAuth 2.0 | Авторизация | REST API и интеграции |
| OpenID Connect | Аутентификация | Современные веб и mobile приложения |
| SAML 2.0 | Enterprise SSO | Корпоративные системы |
OAuth отвечает на вопрос «что разрешено?», OpenID Connect — «кто пользователь?».
Безопасность OAuth 2.0
Безопасность OAuth зависит не только от протокола, но и от правильной реализации.
| Риск | Как защититься |
|---|---|
| Кража access token | Короткое время жизни токена |
| Перехват authorization code | PKCE |
| XSS-атаки | Не хранить токены в localStorage |
| Подмена redirect_uri | Строгая валидация URI |
| Фишинг | MFA и trusted domains |
Лучшие практики OAuth
- используйте PKCE;
- включайте MFA;
- ограничивайте scopes;
- используйте HTTPS;
- делайте access token короткоживущими;
- не используйте Implicit Flow.
Преимущества и недостатки OAuth 2.0
OAuth 2.0 стал стандартом благодаря безопасности и гибкости, но у него есть сложности в реализации и потенциальные уязвимости.
| Преимущества | Недостатки |
|---|---|
| ✅ Пользователь не передаёт пароль приложению. ✅ Можно выдавать ограниченные права (scopes). ✅ Короткоживущие токены снижают риск. ✅ Поддержка refresh token для долгих сессий. ✅ Стандарт, реализованный во всех популярных сервисах. | ❌ Сложность настройки (несколько потоков, endpoints). ❌ Нет встроенной аутентификации (нужен OIDC). ❌ Потенциальные уязвимости при неправильной реализации (например, перехват кода). ❌ Требует защищённого хранения client_secret в серверных приложениях. |
Частые ошибки при внедрении OAuth 2.0
Неправильная настройка OAuth 2.0 может привести к утечке токенов и компрометации API.
| Ошибка | Последствие | Решение |
|---|---|---|
| Использование Implicit Flow | Утечка токена (перехват в URL) | Использовать PKCE |
| Хранение токена в localStorage | XSS-кража | Хранить в памяти приложения или в httpOnly cookie (с backend). |
| Слишком длинный срок жизни (TTL) токена доступа (Access Token) | Рост рисков. Увеличенное окно для атаки | Ограничить access token 5–60 минутами |
| Отсутствие проверки state | CSRF-атаки | Всегда проверять state |
| Слабая проверка redirect_uri | Подмена редиректа, кража кода авторизации ( authorization code) | Валидировать точное совпадение redirect_uri |
| Использование парольного гранта (Password) без острой необходимости | Клиент видит пароль пользователя | Заменить на Authorization Code Flow. |
Популярные OAuth-провайдеры
Большинство современных платформ поддерживают OAuth 2.0 из коробки.
| Провайдер | Использование |
|---|---|
| Google OAuth | Google API и вход через Google |
| VK ID | Авторизация через VK |
| GitHub OAuth | Developer интеграции |
| Microsoft Entra ID | Enterprise OAuth и OIDC |
| Keycloak | Open Source IAM |
| Okta | Корпоративный IAM |
Примеры OAuth интеграций: как использовать с CRM, ERP и внешними API
OAuth — стандарт для безопасных интеграций между системами. Например, CRM может получать данные из Google Sheets, а ERP — отправлять счета в банк через API.
Пример 1 — CRM и Google Sheets
CRM получает access token и автоматически обновляет таблицы продаж.
Пример 2 — Интернет-магазин и банк
ERP получает доступ к банковскому API для проверки платежей.
Пример 3 — ELMA365 и Telegram Bot API
OAuth позволяет безопасно подключать внешние сервисы без хранения паролей пользователей.
Выводы
OAuth 2.0 — ключевой стандарт авторизации для API, SaaS и современных интеграций.
Сегодня OAuth используется практически везде:
- REST API;
- мобильные приложения;
- CRM и ERP;
- социальные логины;
- облачные сервисы;
- банковские API.
Для безопасной реализации используйте:
- Authorization Code Flow + PKCE;
- короткоживущие access token;
- MFA;
- HTTPS;
- валидацию redirect_uri;
- минимальные scopes.
📚 Читайте также:
FAQ по OAuth 2.0
Ответы на самые популярные вопросы по OAuth авторизации.
Что такое OAuth простыми словами?
Это способ дать приложению ограниченный доступ к данным без передачи пароля.
Что такое OAuth-авторизация?
OAuth-авторизация — это процесс, при котором приложение получает от имени пользователя ограниченный доступ к его данным на другом сервисе без получения пароля.
OAuth — это безопасно?
Да, при правильной реализации: HTTPS, PKCE, MFA и короткие access token.
В чем разница между аутентификацией и авторизацией в OAuth 2.0?
Аутентификация — подтверждение личности («кто ты»). Авторизация — проверка разрешений («что тебе можно»). OAuth 2.0 решает именно авторизацию, а не аутентификацию.
OAuth 2.0 аутентификация — это правильно?
Нет, OAuth 2.0 — это протокол авторизации, а не аутентификации. Он не отвечает на вопрос «кто пользователь». Для аутентификации поверх OAuth 2.0 используется OpenID Connect (OIDC), который добавляет ID token. Термин «OAuth аутентификация» технически неверен, но часто встречается в обиходе; правильно говорить «авторизация OAuth 2.0».
Чем отличается OAuth 2.0 от OAuth 1.0?
OAuth 1.0 требовал подписи каждого запроса (сложно). OAuth 2.0 использует HTTPS и токены, что проще и безопаснее при правильной настройке.
Что такое OAuth access token?
Временный токен доступа к API.
Что такое OAuth refresh token?
Токен для автоматического обновления access token.
Для чего нужен OAuth в API?
Для безопасного доступа приложений к REST API.
Что такое Scope в OAuth 2.0?
Scope — это строка, определяющая, какие права запрашивает клиент (например, «read_profile», «write_posts»). Пользователь видит эти права при выдаче согласия.
Что лучше — OAuth или SAML?
OAuth лучше для API и мобильных приложений, SAML — для корпоративного SSO.
OAuth и OpenID Connect — в чем разница?
OAuth отвечает за авторизацию, OIDC — за аутентификацию.
Что такое PKCE?
Механизм защиты OAuth от перехвата authorization code.
Можно ли использовать OAuth 2.0 без сервера авторизации?
Нет, OAuth 2.0 предполагает наличие сервера авторизации. Для простых случаев без стороннего IdP можно использовать само-выданные токены, но это уже не OAuth.