Что такое OAuth 2.0 и как он работает

OAuth 2.0 — стандарт, который позволяет одному приложению получить доступ к данным пользователя в другом сервисе, не получая при этом его пароль. Вместо учётных данных приложение получает токен: ограниченный по правам, по времени жизни и отзываемый в любой момент.

Ключевая идея формулируется одной строкой: вы выдаёте доступ, а не свои учётные данные.

Чем OAuth не является

С этого стоит начать, потому что именно здесь возникает большинство ошибок проектирования.

OAuth — это не про вход в систему. Он отвечает на вопрос «что этому приложению разрешено», но не на вопрос «кто этот пользователь». Приложение, использующее «чистый» OAuth как способ авторизации пользователя, знает лишь то, что кто-то выдал разрешение — но не может достоверно установить личность. Для входа нужен OIDC, надстройка над OAuth, добавляющая ID-токен.

OAuth — не замена многофакторной аутентификации. Он не проверяет пользователя вообще: проверка происходит на стороне провайдера до выдачи токена.

OAuth не безопасен «из коробки». Слишком широкие права, бессрочные токены и свободные правила перенаправления превращают корректный по букве стандарта обмен в дыру.

Как это работает

Рассмотрим типовой сценарий: пользователь подключает стороннюю аналитическую панель к вашему сервису.

1. Запрос доступа. Панель перенаправляет пользователя к провайдеру и указывает, какие именно права ей нужны.
2. Согласие пользователя. Провайдер показывает экран согласия: какое приложение, к каким данным и в каком объёме просит доступ. Пользователь подтверждает или отказывает.
3. Выдача токена. После подтверждения приложение получает access-токен. Пароль пользователя оно не видит ни на одном шаге.
4. Обращение к API. Приложение прикладывает токен к каждому запросу. Сервер проверяет подпись, срок действия и права.

Токен ограничен: он даёт ровно те права, которые были запрошены и одобрены, живёт ограниченное время и может быть отозван без смены пароля.

Области видимости

Область видимости (scope) — это перечень прав, которые запрашивает приложение. Правильно спроектированные области — основа безопасности всей схемы.

Плохо: одна область full_access, дающая всё сразу. Такое приложение при компрометации отдаёт злоумышленнику полный контроль.

Хорошо: раздельные права на чтение и запись, отдельные области для разных групп данных. Приложению для построения отчётов достаточно чтения — записи оно получать не должно.

Принцип простой: минимально необходимые права, и ни одним больше.

Типы потоков

Authorization Code — для приложений с серверной частью. Наиболее защищённый вариант, обмен кода на токен идёт между серверами.

Authorization Code с PKCE — для мобильных приложений и SPA, которые не могут надёжно хранить секрет. Дополнительная криптографическая проверка не позволяет использовать перехваченный код.

Client Credentials — для межсервисного взаимодействия, где пользователя нет вообще. Сервис получает токен от своего имени.

Resource Owner Password — устаревший поток, при котором приложение принимает пароль пользователя напрямую. Противоречит самой идее OAuth, использовать не следует.

Практическая ценность для администратора

Мгновенный отзыв доступа. Скомпрометированный токен отзывается за секунды, без сброса паролей и без влияния на другие интеграции.

Централизованная настройка. Права выдаются на стороне провайдера, менять код приложений для их корректировки не нужно.

Прозрачное отключение подрядчиков. Внешнему исполнителю выдаётся токен с ограниченным сроком. По окончании работ доступ прекращается сам, без ручной чистки учётных записей.

Аудит. Видно, какое приложение, когда и к каким данным обращалось.

Частые ошибки внедрения

Бессрочные токены. Токен без срока действия — это пароль, который никогда не меняется, только хуже: он лежит в конфигурации и логах.

Подстановочные символы в redirect URI. Разрешение вида https://*.example.com/* позволяет увести токен на подконтрольный злоумышленнику поддомен.

Хранение токенов в localStorage. Любой межсайтовый скрипт получает к ним доступ. Безопаснее — httpOnly-куки.

Игнорирование refresh-токенов. Долгоживущий access-токен вместо пары «короткий access + отзываемый refresh» повышает риск без всякой выгоды.

Отсутствие проверки получателя токена. Токен, выпущенный для одного приложения, не должен приниматься другим.

Как это устроено в Keydee

Keydee выступает сервером авторизации для ваших приложений: выдаёт токены, ведёт учёт выданных разрешений и позволяет отозвать их в любой момент.

• Приложения компании заводятся в кабинете, для каждого настраиваются разрешённые адреса перенаправления и права.
• Клиентские секреты хранятся на стороне провайдера и могут быть перевыпущены без переустановки приложения.
• Межсервисный доступ оформляется отдельными учётными данными приложения — без привязки к живому пользователю.
• Отзыв по устройству. Завершение сессии отзывает разрешения, выданные именно с этого устройства, не затрагивая остальные.
• Журнал. Выдача и отзыв токенов фиксируются с реальным IP-адресом.

Когда что применять

Задача	Решение
Приложение получает доступ к данным пользователя	OAuth 2.0
Нужно достоверно установить личность пользователя	OIDC
Взаимодействие сервисов без участия человека	OAuth, Client Credentials
Вход без пароля с привязкой к устройству	Passkeys поверх OIDC

Протоколы дополняют друг друга: OAuth управляет объёмом доступа, OIDC устанавливает личность, passkeys отвечают за надёжность самого входа.