Открыть сервис
Главная → Блог → OAuth 2.0

OAuth 2.0

OAuth 2.0 — это открытый протокол авторизации, позволяющий предоставить стороннему приложению ограниченный доступ к ресурсам пользователя без передачи ему логина и пароля. Протокол определяет механизм выдачи токенов доступа, которые делегируют права на выполнение определённых действий от имени пользователя. OAuth 2.0 не является протоколом аутентификации, хотя часто используется как основа для систем единого входа (SSI).

История и развитие

Протокол OAuth 1.0 был разработан в 2006–2007 годах группой энтузиастов (включая Блейна Кука, Криса Мессину и Эрана Хаммера) как решение проблемы «парольного антипаттерна» — когда сторонние сервисы вынуждены хранить учётные данные пользователя для доступа к его данным на других платформах (например, для публикации фотографий из одного сервиса в другой). В 2010 году IETF (Инженерный совет Интернета) опубликовал RFC 5849, стандартизировавший OAuth 1.0.

OAuth 2.0, радикально переработанная версия, была опубликована в качестве RFC 6749 в октябре 2012 года. Основные отличия от первой версии:

В 2019 году был опубликован RFC 8414 (OAuth 2.0 Authorization Server Metadata), стандартизирующий обнаружение конечных точек сервера. В 2021 году рабочая группа OAuth выпустила расширение OAuth 2.0 for Browser-Based Applications (Best Current Practice 214), направленное на повышение безопасности в браузерных приложениях.

Участники протокола

В схеме OAuth 2.0 выделяют четыре ключевых участника:

  1. Владелец ресурса (Resource Owner) — пользователь, который имеет право предоставлять доступ к своим данным (например, профиль в социальной сети).
  2. Клиент (Client) — приложение (веб-сайт, мобильное приложение, серверный сервис), которое запрашивает доступ к ресурсам от имени владельца.
  3. Сервер авторизации (Authorization Server) — сервер, выдающий токены доступа после успешной аутентификации владельца ресурса.
  4. Сервер ресурсов (Resource Server) — сервер, хранящий защищённые ресурсы (например, API), который принимает токены доступа и предоставляет данные или выполняет действия.

В реальных реализациях (например, Google, VK) сервер авторизации и сервер ресурсов могут быть разными подсистемами одной платформы или одной и той же системой.

Гранты (типы предоставления разрешений)

OAuth 2.0 определяет четыре основных типа гранта для получения токена доступа:

Authorization Code Grant (Код авторизации)

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

  1. Пользователь переходит по ссылке из клиентского приложения на сервер авторизации.
  2. Пользователь аутентифицируется (вводит логин/пароль) и даёт согласие на запрашиваемые разрешения (scope).
  3. Сервер авторизации перенаправляет браузер пользователя обратно в клиентское приложение, передавая временный code (код авторизации) через URL-параметр.
  4. Клиентское приложение отправляет этот code на сервер авторизации по защищённому каналу (HTTP POST) вместе с client_secret для обмена на access_token и refresh_token.
  5. Сервер авторизации возвращает токены.

Implicit Grant (Неявный грант)

Устаревший (начиная с Best Current Practice 214) тип, предназначенный для чисто клиентских приложений (одностраничные приложения, расширения браузера). Токен доступа возвращался непосредственно в URL-фрагменте (hash) после перенаправления. Из-за уязвимости к перехвату (например, через параметры реферера или логов прокси-сервера) и отсутствия refresh-токена не рекомендуется к применению.

Resource Owner Password Credentials Grant (Парольные учётные данные)

Позволяет клиенту напрямую собирать логин и пароль пользователя и передавать их серверу авторизации для получения токена. Используется только в доверенных сценариях (например, для клиентских приложений самой платформы или в ходе миграции с легаси-систем). Не рекомендуется для сторонних приложений из-за риска перехвата паролей.

Client Credentials Grant (Учётные данные клиента)

Используется для доступа к ресурсам, не привязанным к конкретному пользователю. Клиент (обычно серверное приложение) проходит аутентификацию сам по себе (с помощью client_id и client_secret), получая access_token. Типичный пример — вызов API для управления конфигурацией или получения списка пользователей.

Refresh-токен

Refresh token (токен обновления) — это долгоживущий токен, используемый для получения новых access_token без повторного прохождения всей процедуры авторизации. Он передаётся клиенту вместе с access_token, но хранится более надёжно (например, в защищённом хранилище). Когда access_token истекает, клиент отправляет refresh_token на сервер авторизации, получая новый access_token (а иногда и новый refresh_token). Это позволяет поддерживать сессию пользователя без необходимости повторного ввода пароля.

Токен доступа (Access Token)

Access token (токен доступа) — это строка (чаще всего JSON Web Token, JWT, или просто непрозрачный идентификатор), которую клиент предоставляет серверу ресурсов для доступа к защищённым данным. Токен содержит информацию о разрешениях (scope), времени жизни (обычно от 15 минут до часа) и владельце (субъекте). Сервер ресурсов проверяет токен (либо локально, если он криптографически подписан, либо через внутренний запрос к серверу авторизации) перед выполнением запроса.

Регистрация и аутентификация клиента

Перед использованием OAuth 2.0 разработчик должен зарегистрировать своё приложение у провайдера (например, в консоли разработчика Яндекса или VK). В процессе регистрации выдаются:

Также зачастую указываются разрешённые redirect_uri — адреса, на которые сервер авторизации может перенаправлять пользователя после авторизации. Любая попытка редиректа на другой адрес блокируется.

Безопасность

OAuth 2.0 по умолчанию использует HTTPS для предотвращения перехвата токенов на стадии передачи. Основные уязвимости, такие как перехват кода авторизации (через несоответствие redirect_uri), CSRF-атаки при обмене code на токен, хранение токенов в небезопасных местах (например, в localStorage), многократно документированы. Для снижения рисков применяются:

Стандарт OpenID Connect (OIDC), основанный на OAuth 2.0, добавляет слой аутентификации: он вводит ID Token (JWT), который информирует клиента о том, что пользователь успешно прошёл проверку подлинности.

Недостатки и критика

Применение в России

В Российской Федерации OAuth 2.0 широко применяется для авторизации в сервисах:

Все провайдеры обязаны соблюдать требования Федерального закона «О персональных данных» (152-ФЗ), включая обязанность получать согласие пользователя на передачу данных (что реализуется через scope в OAuth).

Источники

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы