Потоки OAuth 2.0 и типы токенов

OAuth 2.0 определяет четыре роли. Владелец ресурса — пользователь, которому принадлежат данные, например файлы на Google Drive. Клиент — приложение, запрашивающее доступ. Сервер авторизации выдаёт токены доступа, например сервер OAuth компании Google. Сервер ресурсов хранит защищённые данные, например API Google Drive. Понимание этих ролей помогает разобраться в назначении каждого потока.

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

Неявный поток был разработан для браузерных приложений на JavaScript, которые не могли безопасно хранить секреты клиента. Токены возвращались непосредственно во фрагменте URL, минуя обратный канал. В OAuth 2.1 неявный поток признан устаревшим, поскольку PKCE (RFC 7636) позволяет публичным клиентам безопасно использовать поток кода авторизации без секрета клиента.

Поток ROPC позволяет клиентам напрямую получать имя пользователя и пароль пользователя и обменивать их на токены. Он предназначался для полностью доверенных собственных клиентов, но фактически противоречит самой цели OAuth — не позволять приложениям видеть учётные данные пользователей. В OAuth 2.1 этот поток признан устаревшим, и его не следует использовать в новых приложениях.

Поток учётных данных клиента предназначен для аутентификации между машинами (M2M), когда пользователь не участвует в процессе. Клиент напрямую проходит аутентификацию на сервере авторизации с помощью своего идентификатора клиента и секрета, получая токен доступа для собственного использования. Распространённые сценарии: фоновые задания, взаимодействие микросервиса с микросервисом и доступ шлюзов программного интерфейса к внутренним сервисам.

Поток авторизации устройства (RFC 8628) обеспечивает работу OAuth на устройствах с ограниченными возможностями ввода: умных телевизорах, игровых консолях, принтерах и устройствах IoT. Устройство показывает короткий код и URL. Пользователь открывает URL на телефоне или компьютере и подтверждает авторизацию. Устройство периодически опрашивает сервер авторизации, пока пользователь не завершит авторизацию.

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

Токены обновления — это долгоживущие учётные данные, используемые для получения новых токенов доступа после истечения срока действия токена доступа. При замене токена обновления, обязательной в OAuth 2.1 для публичных клиентов, при каждом использовании выдаётся новый токен обновления, а старый становится недействительным. Если используется украденный токен обновления, легитимный клиент обнаруживает его недействительность, что позволяет выявить кражу токена.

RFC 7662 определяет конечную точку проверки токенов, с помощью которой серверы ресурсов могут запросить у сервера авторизации текущий статус непрозрачного токена доступа (активен или неактивен), его область действия, субъект и срок действия. Проверка токенов обеспечивает отзыв в реальном времени: после отзыва токена на сервере авторизации обращения к конечной точке немедленно возвращают active: false.

RFC 7009 определяет конечную точку отзыва токенов, позволяющую клиентам уведомить сервер авторизации о необходимости сделать токен, токен доступа или обновления, недействительным. Это используется при выходе из системы или обнаружении клиентом подозрительной активности. Токены доступа JWT нельзя полностью отозвать без списка отзыва, поскольку серверы ресурсов проверяют их локально, не обращаясь к серверу авторизации.

Области действия OAuth 2.0 определяют конкретные разрешения, которые запрашивает клиент. Сервер авторизации показывает запрошенные области действия пользователю для подтверждения. Серверы ресурсов применяют требования к областям действия для каждой конечной точки. Действует принцип наименьших привилегий: клиенты должны запрашивать только минимально необходимые области действия, а серверы ресурсов должны отклонять запросы с недостаточной областью действия.

Какой поток OAuth 2.0 подходит для инструмента CLI или устройства IoT, которому нужно аутентифицировать пользователя, но у которого нет браузера или клавиатуры?

Поток кода авторизации подходит для приложений с серверной частью. Неявный поток устарел — вместо него следует использовать PKCE. Поток ROPC устарел, поскольку устраняет саму цель OAuth. Поток учётных данных клиента предназначен для взаимодействия между машинами (M2M). Поток авторизации устройства предназначен для устройств с ограниченными возможностями ввода. Токены доступа бывают непрозрачными или JWT. Токены обновления следует заменять. Проверка токенов (RFC 7662) и их отзыв (RFC 7009) дополняют управление токенами.