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

OAuth

OAuth — это открытый протокол авторизации, позволяющий предоставить стороннему приложению или веб-сервису ограниченный доступ к ресурсам пользователя (например, к фотографиям, списку контактов или данным профиля) без передачи ему логина и пароля. Вместо этого протокол использует выдачу токенов доступа, которые определяют права и объём разрешённых действий. OAuth не является протоколом аутентификации (подтверждения личности), хотя часто используется в связке с ней. Наиболее распространённой версией является OAuth 2.0, которая лежит в основе систем «Войти через...» (Single Sign-On) для большинства современных интернет-сервисов.

История

Протокол OAuth был разработан в 2006–2007 годах группой разработчиков Twitter (ныне X), Google и других компаний, столкнувшихся с проблемой безопасного делегирования доступа. Первая версия (OAuth 1.0) была опубликована в декабре 2007 года как запрос комментариев (RFC 5849). Она требовала сложной криптографической подписи каждого запроса, что усложняло реализацию для разработчиков.

В 2010 году началась работа над второй версией (OAuth 2.0), которая была стандартизирована в октябре 2012 года в документе RFC 6749. OAuth 2.0 отказался от обязательной подписи запросов, перейдя на использование HTTPS для защиты каналов связи, и ввёл более гибкую систему типов токенов и потоков авторизации. Это сделало протокол проще в реализации, но потребовало от разработчиков строгого соблюдения мер безопасности, так как компрометация токена могла привести к утечке данных.

Основные понятия

Для понимания работы OAuth необходимо определить ключевые роли и объекты, участвующие в процессе авторизации:

Потоки авторизации (Grant Types)

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

Авторизационный код (Authorization Code)

Наиболее безопасный и распространённый поток, предназначенный для серверных приложений (веб-сайтов). Процесс включает:

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

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

Неявный поток (Implicit Grant)

Упрощённый поток, предназначенный для публичных клиентов (например, одностраничных приложений на JavaScript, работающих в браузере). В этом потоке токен доступа выдаётся непосредственно в URL-перенаправлении после авторизации пользователя. Из-за повышенного риска перехвата токена (через логи браузера, рефереры) этот поток считается менее безопасным и в современных рекомендациях (RFC 8252) заменяется на поток авторизационного кода с использованием PKCE.

Поток с паролем владельца ресурса (Resource Owner Password Credentials Grant)

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

Поток с учётными данными клиента (Client Credentials Grant)

Используется, когда клиент запрашивает доступ к ресурсам от своего имени, а не от имени пользователя (например, серверное приложение, которое обращается к API для получения списка своих же данных). В этом потоке клиент аутентифицируется сам (через client_id и client_secret) и получает токен без участия пользователя.

Поток с кодом подтверждения для PKCE (Proof Key for Code Exchange)

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

Токены и их использование

Токен доступа — это ключевой элемент OAuth. Он может быть представлен в различных форматах:

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

Применение

OAuth 2.0 является стандартом де-факто для децентрализованной авторизации в интернете. Основные области применения:

Безопасность и критика

Несмотря на широкое распространение, OAuth 2.0 имеет ряд уязвимостей, связанных с неправильной реализацией:

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

Интересные факты

Источники

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

На главную BFOmetr →

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