RFC 6749

RFC 6749 — это документ, озаглавленный «The OAuth 2.0 Authorization Framework», который определяет протокол делегирования доступа к ресурсам через HTTP. Разработанный рабочей группой Internet Engineering Task Force (IETF) в 2012 году, он стал стандартом де-факто для авторизации в современных веб-приложениях, мобильных приложениях и API. В отличие от протокола аутентификации, OAuth 2.0 не предоставляет информацию о том, кто является пользователем, а позволяет приложению получить ограниченный доступ к данным пользователя, хранящимся на стороннем сервере, без передачи логина и пароля.

История

Разработка OAuth 2.0 началась в 2010 году как ответ на ограничения первой версии протокола OAuth (RFC 5849). OAuth 1.0 был сложен в реализации, требовал криптографических подписей каждого запроса и не поддерживал мобильные и одностраничные приложения. Рабочая группа IETF, возглавляемая Диком Хардтом (Dick Hardt), поставила задачу создать более простой и гибкий протокол, основанный на использовании токенов доступа, передаваемых через HTTPS.

Основные этапы:

2010 год — начало работы над спецификацией.
2012 год — публикация RFC 6749 как стандарта IETF (Proposed Standard).
2012 год — публикация сопутствующего RFC 6750, описывающего использование Bearer-токенов.
2013–2017 годы — активное внедрение OAuth 2.0 крупными платформами: Google, Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ), Microsoft, GitHub, Amazon.
2019–2020 годы — публикация уточняющих RFC (например, RFC 8252 — OAuth 2.0 for Native Apps, RFC 8705 — OAuth 2.0 Mutual TLS Client Authentication).
2021 год — публикация RFC 9068, определяющего формат JWT Access Token.

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

Протокол OAuth 2.0 оперирует четырьмя ключевыми ролями:

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

Ключевые сущности протокола:

Токен доступа (Access Token) — строка, представляющая собой разрешение на доступ к определенным ресурсам. Обычно имеет ограниченный срок действия.
Токен обновления (Refresh Token) — опциональный токен, используемый для получения нового токена доступа после истечения старого, без повторной аутентификации пользователя.
Область доступа (Scope) — параметр, определяющий, к каким именно данным или действиям предоставляется доступ (например, read, write, email).

Типы грантов (Grant Types)

RFC 6749 определяет четыре основных механизма (гранта) для получения токена доступа, каждый из которых предназначен для разных сценариев использования:

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

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

Клиент перенаправляет пользователя на сервер авторизации.
Пользователь аутентифицируется и дает согласие на доступ.
Сервер авторизации возвращает клиенту временный код авторизации (authorization code) через редирект.
Клиент отправляет этот код на сервер авторизации вместе со своим секретным ключом (client secret) и получает токен доступа (и, опционально, токен обновления).

Этот механизм позволяет избежать передачи токена доступа через браузер пользователя, снижая риск перехвата.

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

Упрощенный тип, предназначенный для одностраничных приложений (SPA) и мобильных приложений, где секретный ключ клиента не может быть надежно сохранен. В этом случае токен доступа возвращается непосредственно в URL-фрагменте после редиректа, без промежуточного кода авторизации. Из-за уязвимости к перехвату токена через реферер или историю браузера, IETF в 2019 году рекомендовал отказаться от этого типа в пользу Authorization Code Grant с PKCE.

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

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

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

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

Расширения и дополнительные механизмы

Стандарт OAuth 2.0 предусматривает возможность расширения. Наиболее значимые дополнения:

PKCE (Proof Key for Code Exchange) — RFC 7636 — механизм, повышающий безопасность Authorization Code Grant для публичных клиентов (SPA, мобильные приложения) путем добавления динамически создаваемого секрета, который не может быть перехвачен.
Device Authorization Grant (Устройства) — RFC 8628 — предназначен для устройств с ограниченным вводом (например, Smart TV, принтеры). Пользователь вводит код на отдельном устройстве (например, смартфоне) для авторизации.
JWT Bearer Token — RFC 9068 — определяет формат токена доступа в виде JSON Web Token (JWT), что позволяет серверу ресурсов проверять токен без обращения к серверу авторизации.
Mutual TLS Client Authentication — RFC 8705 — усиление аутентификации клиента с использованием сертификатов TLS.

Применение

OAuth 2.0 используется в подавляющем большинстве современных API:

Социальные сети — Google, Facebook (принадлежит компании Meta, признанной экстремистской и запрещенной в РФ), VK, Twitter.
Облачные сервисы — Microsoft Azure, Amazon Web Services, Google Cloud.
Платежные системы — PayPal, Stripe.
Умные устройства — авторизация через смартфон для Smart TV, IoT-устройств.
Корпоративные системы — интеграция с Active Directory, LDAP, OpenID Connect (надстройка над OAuth 2.0 для аутентификации).

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

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

Сложность реализации — неправильная настройка параметров (например, отсутствие проверки redirect_uri) может привести к утечке токенов.
Уязвимость к CSRF (межсайтовая подделка запроса) — для защиты требуется использование state-параметра.
Отсутствие встроенной аутентификации — OAuth 2.0 не определяет, как удостовериться в личности пользователя, что привело к созданию OpenID Connect.
Проблемы с токенами обновления — при их утечке злоумышленник может получать новые токены доступа неограниченное время.
Зависимость от HTTPS — протокол предполагает, что все каналы связи защищены TLS, что не всегда выполняется.

Влияние на индустрию

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

OpenID Connect — слой аутентификации поверх OAuth 2.0.
SCIM — протокол для управления пользовательскими данными.
UMA 2.0 — протокол для управления доступом к ресурсам.
FAPI — профиль для финансовых API, требующий повышенной безопасности.

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

RFC 6749 является одним из самых цитируемых документов IETF — по состоянию на 2024 год он имеет более 10 000 цитирований в научных работах и технических документах.
Название «OAuth» происходит от «Open Authorization».
Первая версия протокола (OAuth 1.0) была разработана в 2007 году группой энтузиастов, включая Блейна Кука (Blaine Cook) из Twitter.
В 2020 году IETF выпустила RFC 6749-bis — проект обновления стандарта, который вносит уточнения и исправления, но не меняет основную архитектуру.

Источники

RFC 6749 — The OAuth 2.0 Authorization Framework (IETF, 2012).
RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage (IETF, 2012).
RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients (IETF, 2015).
RFC 8252 — OAuth 2.0 for Native Apps (IETF, 2017).
RFC 8628 — OAuth 2.0 Device Authorization Grant (IETF, 2019).
RFC 9068 — JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (IETF, 2021).
Hardt, D. (2012). «OAuth 2.0: The Complete Guide». O'Reilly Media.
Richer, J. (2017). «OAuth 2.0: Getting Started in Web-Application Security». Manning Publications.

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

На главную BFOmetr →