RFC 7235

RFC 7235 — это спецификация, опубликованная в июне 2014 года в рамках серии документов Request for Comments (RFC) Инженерного совета Интернета (IETF). Она определяет механизм аутентификации доступа к ресурсам в протоколе HTTP/1.1, заменяя и уточняя предыдущую версию, описанную в RFC 2617 (1999 год). RFC 7235 является частью набора стандартов, которые совместно описывают протокол HTTP/1.1 (RFC 7230—7235) и устанавливают единый подход к проверке подлинности клиента на стороне сервера.

Общая характеристика

RFC 7235 формализует протокол HTTP-аутентификации, который позволяет серверу запрашивать у клиента учётные данные (например, имя пользователя и пароль, токен или сертификат) для предоставления доступа к защищённым ресурсам. Основная цель спецификации — обеспечить стандартный, расширяемый и безопасный способ обмена данными аутентификации между клиентом и сервером без необходимости встраивания логики проверки в сам протокол передачи данных.

Спецификация не определяет конкретные методы аутентификации (например, Basic или Digest), а описывает общий каркас (framework) — заголовки, коды состояния и правила обработки. Конкретные схемы аутентификации (например, Basic, Bearer, Digest) определяются отдельными документами (RFC 7617 для Basic, RFC 7616 для Digest, RFC 6750 для Bearer и т.д.) и регистрируются в реестре IANA.

Структура и ключевые элементы

RFC 7235 вводит несколько новых HTTP-заголовков и уточняет работу существующих, а также определяет коды состояния, связанные с аутентификацией.

Заголовки запроса и ответа

• Заголовок Authorization (запрос клиента): содержит учётные данные клиента в формате, зависящем от схемы аутентификации. Обычно имеет вид: Authorization: <тип> <данные>. Например, для схемы Basic: Authorization: Basic dXNlcjpwYXNz (где dXNlcjpwYXNz — это base64-кодированная строка user:pass).
• Заголовок WWW-Authenticate (ответ сервера): отправляется сервером вместе с кодом состояния 401 (Unauthorized) и указывает клиенту, какие схемы аутентификации поддерживаются и какие параметры необходимы. Формат: WWW-Authenticate: <тип> realm="<описание>", <параметры>. Параметр realm (область) определяет защищённое пространство ресурсов, к которому относятся учётные данные.
• Заголовок Proxy-Authenticate (ответ прокси-сервера): аналогичен WWW-Authenticate, но используется для аутентификации на промежуточном прокси-сервере, а не на конечном сервере.
• Заголовок Proxy-Authorization (запрос клиента): аналогичен Authorization, но предназначен для передачи учётных данных прокси-серверу.

Коды состояния

• 401 (Unauthorized): стандартный код ответа сервера, указывающий, что запрос требует аутентификации. Сервер обязан включить в ответ заголовок WWW-Authenticate с указанием поддерживаемых схем.
• 407 (Proxy Authentication Required): аналогичен 401, но для прокси-сервера. В ответ включается заголовок Proxy-Authenticate.

Механизм проверки подлинности

Процесс аутентификации по RFC 7235 обычно выглядит следующим образом:

1. Клиент отправляет запрос к защищённому ресурсу без заголовка Authorization.
2. Сервер возвращает ответ с кодом 401 и заголовком WWW-Authenticate, содержащим одну или несколько схем аутентификации (например, Basic realm="Access to the site").
3. Клиент выбирает подходящую схему (или предлагает свою) и повторяет запрос, добавляя заголовок Authorization с соответствующими учётными данными.
4. Сервер проверяет учётные данные. Если они верны — возвращает запрашиваемый ресурс (код 200). Если нет — может снова вернуть 401 или, в случае повторных неудачных попыток, 403 (Forbidden).

Отличия от RFC 2617

RFC 7235 заменил RFC 2617, который был опубликован в 1999 году и являлся частью HTTP/1.1. Основные изменения и уточнения:

• Уточнение обработки ошибок: RFC 7235 более чётко описывает, как сервер должен реагировать на неверные или отсутствующие учётные данные, включая возможность возврата 403 (Forbidden) при повторных неудачах, а не только 401.
• Удаление устаревших элементов: из спецификации были исключены некоторые неиспользуемые или небезопасные параметры, такие как domain в схеме Digest.
• Улучшение совместимости с прокси: более детально описана работа с заголовками Proxy-Authenticate и Proxy-Authorization, а также взаимодействие клиента с несколькими прокси-серверами.
• Расширяемость: RFC 7235 явно поддерживает регистрацию новых схем аутентификации через IANA, что позволяет использовать, например, токены OAuth 2.0 (схема Bearer) или более современные криптографические методы.

Применение и ограничения

RFC 7235 является основой для большинства веб-приложений, использующих HTTP-аутентификацию. Он широко применяется в:

• Веб-серверах (Apache, Nginx, IIS) для защиты каталогов и файлов.
• API (REST, GraphQL) для аутентификации клиентов (например, с помощью токенов Bearer).
• Прокси-серверах для контроля доступа к интернету.

Однако RFC 7235 имеет ряд ограничений:

• Отсутствие шифрования: сами заголовки Authorization передаются в открытом виде (если не используется HTTPS). Схема Basic, например, кодирует данные в base64, но не шифрует их, что делает её уязвимой для перехвата.
• Отсутствие управления сессиями: протокол не предусматривает механизмов выдачи, обновления или отзыва токенов. Это решается на уровне приложения (например, с помощью OAuth 2.0 или JWT).
• Зависимость от схем: безопасность всей системы зависит от выбранной схемы аутентификации. RFC 7235 лишь определяет, как передавать данные, но не как их проверять.

Критика и альтернативы

Основная критика RFC 7235 связана с его недостаточной безопасностью при использовании без HTTPS. Многие современные веб-приложения отказываются от схемы Basic в пользу более защищённых методов, таких как OAuth 2.0 (RFC 6749) или OpenID Connect, которые строятся поверх HTTP-аутентификации, но добавляют механизмы токенов, областей и перенаправлений. Тем не менее, RFC 7235 остаётся базовым стандартом для всех HTTP-аутентификаций, и его заголовки (Authorization, WWW-Authenticate) используются в большинстве современных протоколов.

Источники

• RFC 7235 — Hypertext Transfer Protocol (HTTP/1.1): Authentication (июнь 2014)
• RFC 2617 — HTTP Authentication: Basic and Digest Access Authentication (июнь 1999)
• RFC 7617 — The 'Basic' HTTP Authentication Scheme (сентябрь 2015)
• RFC 7616 — HTTP Digest Access Authentication (сентябрь 2015)
• RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage (октябрь 2012)
• IANA HTTP Authentication Scheme Registry