OAuth

OAuth — это открытый протокол делегированной авторизации, который позволяет одному приложению получать ограниченный доступ к ресурсам пользователя в другом сервисе без передачи этому приложению пароля. На практике чаще всего используется OAuth 2.0 — современная версия протокола, описанная в RFC 6749. В 2025 году рекомендации по безопасности OAuth 2.0 были дополнены и обновлены в RFC 9700, а в августе 2026 года опубликована отдельная спецификация с актуальными рекомендациями для браузерных приложений.

Главная идея OAuth заключается в разделении аутентификации и авторизации. Пользователь подтверждает свою личность непосредственно у доверенного сервиса, а стороннее приложение получает не пароль, а специальный токен с ограниченными правами. Благодаря этому приложение может работать с разрешенными ресурсами, не получая полный доступ к учетной записи.

Зачем нужен OAuth

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

OAuth решает эту проблему иначе. Пользователь переходит на страницу авторизации самого сервиса, проходит проверку и подтверждает необходимые разрешения. После этого стороннее приложение получает специальный access token, с помощью которого может обращаться только к разрешенным API.

Таким образом, OAuth позволяет:

• не передавать пароль стороннему приложению;
• ограничивать доступ определенными разрешениями;
• задавать срок действия предоставленного доступа;
• отзывать ранее выданные разрешения;
• разделять приложение, сервер авторизации и защищенный ресурс.

Основные участники OAuth

В OAuth 2.0 выделяется несколько ролей. Они могут быть реализованы отдельными серверами или объединяться в одном программном комплексе.

• Resource Owner — владелец ресурса, обычно пользователь, который разрешает приложению доступ.
• Client — приложение, запрашивающее доступ к защищенному ресурсу.
• Authorization Server — сервер авторизации, который взаимодействует с пользователем и выдает токены.
• Resource Server — сервер, на котором находятся защищенные данные и API.

Например, пользователь может работать с мобильным приложением, которое получает разрешение на чтение определенных данных из облачного сервиса. Мобильное приложение является Client, облачный сервис выступает одновременно или раздельно в роли Authorization Server и Resource Server, а пользователь является Resource Owner.

Как работает OAuth 2.0

Наиболее распространенный современный сценарий основан на Authorization Code Flow. В упрощенном виде последовательность выглядит следующим образом.

1. Пользователь запускает приложение и выбирает авторизацию через внешний сервис.
2. Приложение перенаправляет пользователя на Authorization Server.
3. Пользователь проходит аутентификацию и подтверждает запрашиваемые разрешения.
4. Authorization Server возвращает приложению authorization code.
5. Приложение обменивает код на access token.
6. Access token используется для обращения к API Resource Server.
7. При необходимости приложение может получить новый access token с использованием refresh token.

Важный момент заключается в том, что authorization code и access token — разные сущности. Код является временным промежуточным значением, а access token используется для доступа к API. Такой подход позволяет не передавать токен непосредственно через весь пользовательский сценарий авторизации.

Что такое access token

Access token — это учетные данные, которые клиент предъявляет Resource Server для получения разрешенного ресурса. В токене или связанной с ним информации могут определяться область действия, срок жизни и другие параметры доступа.

Например, приложение может получить разрешение только на чтение профиля пользователя. В таком случае наличие access token не означает автоматического получения права изменять пароль, удалять аккаунт или просматривать другие данные.

Токены обычно имеют ограниченный срок действия. Это снижает последствия возможной утечки: украденный токен не должен предоставлять неограниченный доступ на протяжении всего времени существования учетной записи.

Что такое refresh token

Refresh token используется для получения нового access token после истечения его срока действия. Это позволяет не заставлять пользователя заново проходить интерактивную авторизацию при каждом обновлении временного токена.

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

Что такое scope

Scope определяет, какие действия приложение хочет выполнять от имени пользователя. Именно механизм scopes позволяет реализовать принцип минимально необходимых полномочий.

Например, API может предусматривать области:

• profile.read — чтение профиля;
• files.read — чтение файлов;
• files.write — изменение файлов;
• calendar.read — чтение календаря.

Если приложению требуется только чтение профиля, нет необходимости выдавать ему разрешение на изменение файлов. Чем точнее определены scopes, тем меньше потенциальный ущерб при компрометации клиента или токена.

OAuth и вход через Google, Microsoft и другие сервисы

OAuth часто связывают с кнопками «Войти через Google», «Войти через Microsoft» или аналогичными механизмами. Однако технически OAuth предназначен прежде всего для авторизации, то есть делегирования доступа к ресурсам.

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

Зачем нужен PKCE

PKCE (Proof Key for Code Exchange) — механизм защиты Authorization Code Flow от перехвата или подмены authorization code. Клиент заранее создает секретное значение, из которого формируется challenge. После возврата authorization code клиент доказывает, что именно он начал исходный запрос.

Современная рекомендация RFC 9700 требует использовать PKCE для публичных клиентов и рекомендует его также для конфиденциальных клиентов. Этот механизм особенно важен для мобильных приложений и браузерных сценариев, где классическая защита client secret может быть недостаточной.

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

Само использование OAuth не гарантирует безопасность системы. Очень многое зависит от правильной реализации протокола. Актуальные рекомендации IETF уделяют особое внимание защите redirect URI, authorization code, access token и другим элементам протокола.

При проектировании OAuth-инфраструктуры необходимо учитывать:

• использование HTTPS;
• точное сопоставление зарегистрированных redirect URI;
• использование PKCE;
• минимально необходимые scopes;
• короткое время жизни access token;
• безопасное хранение refresh token;
• защиту от повторного использования украденных токенов;
• отказ от устаревших и небезопасных OAuth-сценариев.

RFC 9700, опубликованный IETF в январе 2025 года, обновляет рекомендации по безопасности OAuth 2.0 и прямо указывает на необходимость учитывать реальные атаки и ошибки реализации. В документе также пересматривается использование некоторых старых механизмов, которые больше не считаются подходящими для современных систем.

OAuth в веб-приложениях

OAuth используется в интернет-магазинах, SaaS-сервисах, мобильных приложениях, корпоративных системах и API-платформах. Например, CRM может получить разрешение на чтение данных из другого сервиса, а мобильное приложение — доступ к отдельным функциям учетной записи.

Для браузерных приложений особенно важны корректная обработка перенаправлений, защита authorization code и предотвращение атак через подмену или неправильную обработку redirect URI. В августе 2026 года IETF опубликовала RFC 10017, посвященный современным требованиям безопасности OAuth 2.0 именно для browser-based applications.

OAuth 2.0 и OAuth 2.1

Название OAuth 2.0 не означает, что протокол представляет собой одну единственную схему авторизации. Это целая архитектура, включающая различные сценарии и расширения.

Развитие стандарта направлено на постепенное исключение исторически появившихся небезопасных вариантов и объединение современных рекомендаций. RFC 9700 уже обновляет OAuth 2.0 с учетом накопленного практического опыта, а рекомендации по безопасности должны учитываться при дальнейшем развитии OAuth 2.1.

Преимущества и ограничения OAuth

Главное преимущество OAuth заключается в том, что стороннему приложению не требуется знать пароль пользователя. Доступ можно предоставить конкретному приложению, ограничить его scope и затем отозвать.

Однако OAuth является достаточно сложным протоколом. Ошибки в настройке redirect URI, хранении токенов, проверке параметров или обработке authorization code могут привести к серьезным последствиям. Поэтому разработчикам рекомендуется использовать проверенные библиотеки и следовать актуальным рекомендациям IETF, а не реализовывать протокол самостоятельно с нуля.

Выводы

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

Ключевыми элементами являются Authorization Server, Client, Resource Server, access token, refresh token и scopes. Для современных Authorization Code Flow важную роль играет PKCE, а безопасность redirect URI и токенов должна рассматриваться как обязательная часть архитектуры.

При этом OAuth не следует путать с полноценной системой аутентификации. Если требуется стандартизированно определить личность пользователя при входе, поверх OAuth 2.0 обычно используется OpenID Connect.

FAQ

Что такое OAuth простыми словами?

OAuth позволяет дать приложению разрешение на доступ к определенным данным другого сервиса без передачи приложению пароля от учетной записи.

OAuth — это протокол аутентификации?

В первую очередь OAuth предназначен для авторизации и делегирования доступа. Для идентификации пользователя при входе обычно применяется OpenID Connect.

Что такое access token?

Access token — это учетные данные, с помощью которых клиент получает доступ к разрешенным защищенным ресурсам API.

Зачем нужен refresh token?

Refresh token позволяет получить новый access token после истечения его срока действия без повторного интерактивного входа пользователя.

Что такое PKCE?

PKCE — механизм защиты Authorization Code Flow, который связывает authorization code с клиентом, начавшим процесс авторизации, и помогает предотвратить его перехват и использование злоумышленником.

Безопасен ли OAuth?

OAuth может обеспечивать высокий уровень безопасности при корректной реализации, но неправильная настройка redirect URI, токенов, scopes и других компонентов способна привести к уязвимостям.

Чем OAuth отличается от OpenID Connect?

OAuth предназначен для делегирования доступа к ресурсам, а OpenID Connect добавляет поверх OAuth механизм стандартизированной идентификации пользователя.

Можно ли использовать OAuth для API?

Да. Защита API является одним из основных практических сценариев применения OAuth 2.0.

Дополнительная информация:

• Официальная спецификация OAuth 2.0 — RFC 6749: The OAuth 2.0 Authorization Framework
• Актуальные рекомендации по безопасности OAuth 2.0 — RFC 9700: Best Current Practice for OAuth 2.0 Security
• OAuth 2.0 для браузерных приложений — RFC 10017: OAuth 2.0 for Browser-Based Applications
• OAuth 2.0 — официальный информационный ресурс OAuth
• Документы IETF по OAuth — OAuth Working Group