RFC 7235 | Протокол передачи гипертекста (HTTP/1.1): Аутентификация

Аннотация

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

Скачать оригинальную версию документа на английском языке RFC 7235 PDF

Оглавление

1. Введение
1.1. Соответствие и обработка ошибок
1.2. Синтаксическая нотация
2. Структура Проверки Подлинности Доступа
2.1. Задача и ответ
2.2. Пространство Защиты (Realm)
3. Определения кода состояния
3.1. Код 401 — Неавторизованный
3.2. Код 407 — Требуется прокси-аутентификация
4. Определения поля заголовка
4.1. Заголовок WWW-Authenticate
4.2. Заголовок Authorization
4.3. Заголовок Proxy-Authenticate
4.4. Заголовок Proxy-Authorization
5. Соображения IANA
5.1. Реестр схемы аутентификации
5.1.1. Процедура
5.1.2. Соображения для новых схем аутентификации
5.2. Регистрация кода статуса
5.3. Регистрация поля заголовка
6. Вопросы безопасности
6.1. Конфиденциальность учетных данных
6.2. Учетные данные аутентификации и незанятые клиенты
6.3. Пространства защиты
7. Благодарности
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Приложение A. Изменения по сравнению с RFC 2616 и 2617
Приложение B. Импортированный ABNF
Приложение C. Собранный ABNF
Индекс
Адреса авторов

1. Введение

HTTP обеспечивает общую основу для управления доступом и аутентификации через расширяемый набор схем аутентификации запрос-ответ, которые могут использоваться сервером для запроса клиента и клиентом для предоставления информации аутентификации. Этот документ определяет аутентификацию HTTP/1.1 в терминах архитектуры, определенной в «Протоколе передачи гипертекста (HTTP/1.1): синтаксис сообщений и маршрутизация» [RFC7230 #], включая общую структуру, ранее описанную в «Аутентификация HTTP: базовая и дайджест-аутентификация доступа» [RFC2617 #] и связанные поля и коды состояния, ранее определенные в «Протокол передачи гипертекста — HTTP/1.1» [RFC2616 #].

В Реестре схем аутентификации IANA (раздел 5.1) перечислены зарегистрированные схемы аутентификации и их соответствующие спецификации, включая «базовую» и «дайджест» схемы аутентификации, ранее определенные RFC 2617 #.

1.1. Соответствие и обработка ошибок

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

Критерии соответствия и соображения, касающиеся обработки ошибок, определены в разделе 2.5 [RFC7230 #].

1.2. Синтаксическая нотация

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) в [RFC5234 #] с расширением списка, определенным в разделе 7 [RFC7230 #], который позволяет компактно определять списки, разделенные запятыми, используя оператор решётки «#» (аналогично как оператор звёздочки ‘*’ указывает на повторение). Приложение B описывает правила, импортированные из других документов. Приложение C показывает собранную грамматику со всеми операторами списка, расширенными до стандартной записи ABNF.

2. Структура Проверки Подлинности Доступа

2.1. Задача и ответ

HTTP предоставляет простую структуру аутентификации «запрос-ответ», которая может использоваться сервером для вызова запроса клиента и клиентом для предоставления информации аутентификации. Он использует нечувствительный к регистру токен в качестве средства для идентификации схемы аутентификации, за которой следует дополнительная информация, необходимая для достижения аутентификации через эту схему. Последний может быть либо разделенным запятыми списком параметров, либо отдельной последовательностью символов, способной содержать информацию в кодировке base64.

Параметры аутентификации — это пары имя = значение, где маркер имени сопоставляется без учета регистра, и каждое имя параметра ДОЛЖНО встречаться только один раз за вызов.

auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="

Синтаксис token68 допускает 66 незарезервированных символов URI ([RFC3986 #]), а также несколько других, так что он может содержать кодировку base64, base64url (алфавит URL и имени файла), base32 или base16 (hex) с заполнением или без него, но без пробелов ([RFC4648 #]).

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

Ответное сообщение 407 (Требуется проверка подлинности прокси-сервера) используется прокси-сервером для запроса авторизации клиента, включая поле заголовка Proxy-Authenticate, содержащее, по крайней мере, один запрос, применимый к прокси-серверу для запрошенного ресурса.

challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

Примечание. Многие клиенты не могут проанализировать запрос, содержащий неизвестную схему. Обходной путь для этой проблемы — сначала перечислить хорошо поддерживаемые схемы (например, «базовые»).

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

Клиент, который желает аутентифицировать себя с прокси-сервером — обычно, но не обязательно, после получения 407 (Требуется аутентификация прокси-сервера) — может сделать это, включив в заголовок поле Proxy-Authorization.

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

credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

После получения запроса на защищенный ресурс, который пропускает учетные данные, содержит недопустимые учетные данные (например, неверный пароль) или частичные учетные данные (например, когда схема аутентификации требует более одной обратной передачи), серверу происхождения СЛЕДУЕТ отправить 401 (неавторизованный ) ответ, содержащий поле заголовка WWW-Authenticate, по крайней мере, с одним (возможно, новым) запросом, применимым к запрашиваемому ресурсу.

Аналогичным образом, после получения запроса, который пропускает учетные данные прокси или содержит недействительные или частичные учетные данные прокси, прокси, который требует аутентификации, СЛЕДУЕТ генерировать ответ 407 (Требуется аутентификация прокси), который содержит поле заголовка Proxy-Authenticate, по крайней мере с одним (возможно, новым) вызов применим к прокси.

Сервер, который получает действительные учетные данные, которые не подходят для получения доступа, должен ответить кодом состояния 403 (Запрещено) (Раздел 6.5.3 [RFC7231 #]).

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

2.2. Пространство Защиты (Realm)

Параметр аутентификации «realm» зарезервирован для использования схемами аутентификации, которые хотят указать объем защиты.

Область защиты определяется каноническим корневым URI (схема и компоненты полномочий действующего URI запроса; см. Раздел 5.5 [RFC7230 #]) сервера, к которому осуществляется доступ, в сочетании со значением области, если таковое имеется. Эти области позволяют разделить защищенные ресурсы на сервере на набор защитных пространств, каждое со своей собственной схемой аутентификации и / или базой данных авторизации. Значение области (realm value) — это строка, обычно назначаемая исходным сервером, которая может иметь дополнительную семантику, специфичную для схемы аутентификации. Обратите внимание, что ответ может иметь несколько проблем с одной и той же схемой аутентификации, но с разными областями.

Область защиты определяет домен, к которому могут автоматически применяться учетные данные. Если предыдущий запрос был авторизован, пользовательский агент МОЖЕТ повторно использовать те же учетные данные для всех других запросов в этом пространстве защиты в течение периода времени, определяемого схемой аутентификации, параметрами и / или пользовательскими настройками (такими как настраиваемое время ожидания бездействия). Если это специально не разрешено схемой аутентификации, одно пространство защиты не может выходить за пределы области действия своего сервера.

По историческим причинам отправитель ДОЛЖЕН генерировать только синтаксис в кавычках. Получателям может потребоваться поддержка синтаксиса токенов и строк в кавычках для максимальной совместимости с существующими клиентами, которые принимают обе записи в течение длительного времени.

3. Определения кода состояния

3.1. Код 401 — Несанкционированный

Код состояния 401 (неавторизованный) указывает, что запрос не был применен, поскольку в нем отсутствуют действительные учетные данные аутентификации для целевого ресурса. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее, по крайней мере, один запрос, применимый к целевому ресурсу.

Если в запрос включены учетные данные для проверки подлинности, то в ответе 401 указывается, что для этих учетных данных было отказано в авторизации. Пользовательский агент МОЖЕТ повторить запрос с новым или замененным полем заголовка Авторизация (Раздел 4.2). Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации, по крайней мере, один раз, тогда пользовательский агент ДОЛЖЕН представить приложенное представление пользователю, поскольку он обычно содержит соответствующую диагностическую информацию.

3.2. Код 407 — Требуется прокси-аутентификация

Код состояния 407 (Требуется проверка подлинности прокси-сервера) аналогичен 401 (Неавторизованный), но он указывает, что клиент должен аутентифицировать себя, чтобы использовать прокси-сервер. Прокси ДОЛЖЕН отправить поле заголовка Proxy-Authenticate (раздел 4.3), содержащее запрос, применимый к этому прокси для целевого ресурса. Клиент МОЖЕТ повторить запрос с новым или замененным полем заголовка Proxy-Authorization (Раздел 4.4).

4. Определения поля заголовка

Этот раздел определяет синтаксис и семантику полей заголовка, связанных с платформой аутентификации HTTP.

4.1. Заголовок WWW-Authenticate

Поле заголовка «WWW-Authenticate» указывает схему (ы) аутентификации и параметры, применимые к целевому ресурсу.

WWW-Authenticate = 1#challenge

Сервер, генерирующий ответ 401 (неавторизованный), ДОЛЖЕН отправить поле заголовка WWW-Authenticate, содержащее, по крайней мере, один запрос. Сервер МОЖЕТ генерировать поле заголовка WWW-Authenticate в других ответных сообщениях, чтобы указать, что предоставление учетных данных (или других учетных данных) может повлиять на ответ.

Прокси-сервер, пересылающий ответ, НЕ ДОЛЖЕН изменять поля WWW-Authenticate в этом ответе.

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

Например:

WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

Это поле заголовка содержит две проблемы; один для схемы «Newauth» со значением области «apps» и двумя дополнительными параметрами «type» и «title«, а другой для схемы «Basic» со значением области «simple«.

Примечание. При создании грамматики задачи также используется синтаксис списка. Следовательно, последовательность запятой, пробела и запятой может рассматриваться как относящаяся к предыдущему вызову, или как пустая запись в списке вызовов. На практике эта неоднозначность не влияет на семантику значения поля заголовка и, таким образом, безвредна.

4.2. Заголовок Authorization

Поле заголовка «Authorization» позволяет агенту пользователя аутентифицироваться на сервере происхождения — обычно, но не обязательно, после получения ответа 401 (Несанкционированный). Его значение состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрашиваемого ресурса.

Authorization = credentials

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

Прокси-сервер, пересылающий запрос, НЕ ДОЛЖЕН изменять любые поля Authorization в этом запросе. См. Раздел 3.2 [RFC7234 #] для получения подробной информации и требований, касающихся обработки поля Authorization кешами HTTP.

4.3. Заголовок Proxy-Authenticate

Поле заголовка «Proxy-Authenticate» состоит как минимум из одного запроса, который указывает схему (ы) аутентификации и параметры, применимые к прокси для этого эффективного URI запроса (Раздел 5.5 [RFC7230 #]). Прокси-сервер ДОЛЖЕН отправлять хотя бы одно поле заголовка Proxy-Authenticate в каждом генерируемом им ответе 407 (Proxy Authentication Required).

Proxy-Authenticate = 1#challenge

В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применяется только к следующему исходящему клиенту в цепочке ответов. Это потому, что только клиент, который выбрал данный прокси-сервер, вероятно, будет иметь учетные данные, необходимые для аутентификации. Однако, когда несколько прокси-серверов используются в одном административном домене, таких как офисные и региональные прокси-серверы кэширования в большой корпоративной сети, обычно пользовательские агенты генерируют учетные данные и пропускают их через иерархию до момента их использования. Следовательно, в такой конфигурации будет выглядеть так, как будто Proxy-Authenticate пересылается, потому что каждый прокси-сервер будет отправлять один и тот же набор вызовов.

Обратите внимание, что соображения синтаксического анализа для WWW-Authenticate применимы и к этому полю заголовка; см. Раздел 4.1 для деталей.

4.4. Заголовок Proxy-Authorization

Поле заголовка «Proxy-Authorization» позволяет клиенту идентифицировать себя (или своего пользователя) для прокси, который требует аутентификации. Его значение состоит из учетных данных, содержащих информацию аутентификации клиента для прокси и / или области запрашиваемого ресурса.

Proxy-Authorization = credentials

В отличие от авторизации, поле заголовка Proxy-Authorization применяется только к следующему входящему прокси, который потребовал аутентификацию с использованием поля Proxy-Authenticate. Когда в цепочке используется несколько прокси, поле заголовка Proxy-Authorization используется первым входящим прокси, который ожидал получить учетные данные. Прокси МОЖЕТ передавать учетные данные из запроса клиента следующему прокси, если это механизм, с помощью которого прокси совместно аутентифицируют данный запрос.

5. Соображения IANA

5.1. Реестр схемы аутентификации

«Реестр схем проверки подлинности протокола передачи гипертекста (HTTP)» определяет пространство имен для схем проверки подлинности в запросах и учетных данных. Он был создан и теперь поддерживается по адресу <http://www.iana.org/assignments/http-authschemes>.

5.1.1. Процедура

Регистрации ДОЛЖНЫ включать следующие поля:

  • Имя схемы аутентификации
  • Указатель на текст спецификации
  • Примечания (необязательно)

Значения, которые необходимо добавить в это пространство имен, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

5.1.2. Соображения для новых схем аутентификации

Существуют определенные аспекты HTTP Authentication Framework, которые накладывают ограничения на работу новых схем аутентификации:

o Предполагается, что HTTP-аутентификация не имеет состояния: вся информация, необходимая для аутентификации запроса, ДОЛЖНА быть предоставлена ​​в запросе, а не зависеть от сервера, запоминающего предыдущие запросы. Аутентификация, основанная на базовом соединении или связанная с ним, выходит за рамки данной спецификации и является ошибочной по своей сути, если не предприняты шаги, чтобы гарантировать, что соединение не может быть использовано какой-либо стороной, кроме аутентифицированного пользователя (см. Раздел 2.3 [RFC7230 #]). ,

o Параметр аутентификации «realm» зарезервирован для определения защитных пространств, как описано в разделе 2.2. Новые схемы НЕ ДОЛЖНЫ использовать его таким образом, который несовместим с этим определением.

o Нотация «token68» была введена для совместимости с существующими схемами аутентификации и может использоваться только один раз для каждого запроса или удостоверения. Таким образом, новые схемы должны использовать вместо этого синтаксис auth-param, потому что иначе будущие расширения будут невозможны.

o Разбор запросов и учетных данных определяется этой спецификацией и не может быть изменен новыми схемами аутентификации. Когда используется синтаксис auth-param, все параметры должны поддерживать синтаксис как токена, так и строки в кавычках, а синтаксические ограничения должны быть определены для значения поля после синтаксического анализа (т.е. обработка строки в кавычках). Это необходимо, чтобы получатели могли использовать универсальный синтаксический анализатор, который применяется ко всем схемам аутентификации.

Примечание. Тот факт, что синтаксис значения для параметра «realm» ограничен строкой в ​​кавычках, был неправильным выбором, который нельзя повторять для новых параметров.

o Определения новых схем должны определять обработку неизвестных параметров расширения. В общем, правило «must-ignore» (должен игнорировать) предпочтительнее, чем правило «must-understand» (должен понимать), потому что в противном случае будет сложно ввести новые параметры в присутствии унаследованных получателей. Кроме того, полезно описать политику определения новых параметров (например, «обновить спецификацию» или «использовать этот реестр»).

o Схемы аутентификации должны документировать, могут ли они использоваться при аутентификации на сервере происхождения (т. е. с использованием WWW-Authenticate) и / или при проверке подлинности через прокси (т. е. с использованием Proxy-Authenticate).

o Учетные данные, передаваемые в поле заголовка авторизации, являются специфическими для пользовательского агента и, следовательно, оказывают такое же влияние на HTTP-кэши, как и «private» директива ответа Cache-Control (раздел 5.2.2.6 [RFC7234 #]), в пределах области действия. запроса, в котором они появляются.

Следовательно, новые схемы аутентификации, которые выбирают не переносить учетные данные в поле заголовка Authorization (например, используя недавно определенное поле заголовка), должны будут явно запретить кэширование, предписывая использование любой из директив запроса Cache-Control (например, «no-store », раздел 5.2.1.5 [RFC7234 #]) или директивы ответа (например, «private»).

5.2. Регистрация кода статуса

«Реестр кодов состояния протокола передачи гипертекста (HTTP)», расположенный по адресу <http://www.iana.org/assignments/http-status-codes>, обновлен следующими регистрациями:

Код состоянияОписаниеОпределено в  …
401Неразрешенный (Unauthorized)Раздел 3.1
407Требуется проверка подлинности прокси (Proxy Authentication Required)Раздел 3.2

Таблица

5.3. Регистрация поля заголовка

Поля заголовка HTTP регистрируются в реестре «Заголовки сообщений», который ведется по адресу <http://www.iana.org/assignments/message-headers/>.

Этот документ определяет следующие поля заголовка HTTP, поэтому реестр «Имена полей заголовка постоянного сообщения» был соответствующим образом обновлен (см. [BCP90]).

Имя поля заголовкаПротоколСтатусОпределено в  …
AuthorizationhttpstandardРаздел 4.2
Proxy-AuthenticatehttpstandardРаздел 4.3
Proxy-AuthorizationhttpstandardРаздел 4.4
WWW-AuthenticatehttpstandardРаздел 4.1

Таблица

Контроллер изменений: «IETF (iesg@ietf.org) — Целевая рабочая группа по Интернету».

6. Вопросы безопасности

Этот раздел предназначен для информирования разработчиков, поставщиков информации и пользователей об известных проблемах безопасности, связанных с HTTP-аутентификацией. Более общие соображения безопасности рассматриваются в сообщениях HTTP [RFC7230 #] и семантике [RFC7231 #].

Все, что касается темы HTTP-аутентификации, является соображением безопасности, поэтому приведенный ниже список соображений не является исчерпывающим. Кроме того, он ограничивается соображениями безопасности, касающимися структуры аутентификации, в целом, а не обсуждением всех потенциальных соображений для конкретных схем аутентификации (которые должны быть документированы в спецификациях, которые определяют эти схемы). Различные организации поддерживают актуальную информацию и ссылки на текущие исследования в области безопасности веб-приложений (например, [OWASP]), включая распространенные ошибки при внедрении и использовании схем аутентификации, найденных на практике.

6.1. Конфиденциальность учетных данных

Структура аутентификации HTTP не определяет единого механизма для сохранения конфиденциальности учетных данных; вместо этого каждая схема аутентификации определяет способ кодирования учетных данных перед передачей. Хотя это обеспечивает гибкость для разработки будущих схем аутентификации, этого недостаточно для защиты существующих схем, которые сами по себе не обеспечивают конфиденциальности или которые не обеспечивают достаточной защиты от атак воспроизведения. Кроме того, если сервер ожидает учетные данные, которые являются специфическими для каждого отдельного пользователя, обмен этими учетными данными будет иметь эффект идентификации этого пользователя, даже если содержимое в учетных данных остается конфиденциальным.

HTTP зависит от свойств безопасности нижележащего соединения сеансового уровня транспорта, чтобы обеспечить конфиденциальную передачу полей заголовка. Другими словами, если сервер ограничивает доступ для аутентифицированных пользователей, использующих эту платформу, сервер должен гарантировать, что соединение должным образом защищено в соответствии с характером используемой схемы аутентификации. Например, сервисы, которые зависят от индивидуальной аутентификации пользователя, часто требуют, чтобы соединение было защищено с помощью TLS («Безопасность транспортного уровня», [RFC5246 #]) до обмена какими-либо учетными данными.

6.2. Учетные данные аутентификации и незанятые клиенты

Существующие HTTP-клиенты и пользовательские агенты обычно сохраняют информацию аутентификации на неопределенный срок. HTTP не предоставляет серверу-источнику механизм, позволяющий клиентам отбрасывать эти кэшированные учетные данные, поскольку протокол не знает, как пользовательские агенты получают или управляют учетными данными. Механизмы истечения срока действия или отзыва учетных данных могут быть указаны как часть определения схемы аутентификации.

Обстоятельства, при которых кэширование учетных данных может мешать модели безопасности приложения, включают, но не ограничиваются:

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

Пользовательским агентам, которые кэшируют учетные данные, предлагается предоставить легкодоступный механизм для удаления кэшированных учетных данных под контролем пользователя.

6.3. Пространства защиты

Схемы аутентификации, которые основаны исключительно на механизме «realm» (области) для создания пространства защиты, будут предоставлять учетные данные всем ресурсам на сервере происхождения. Клиенты, которые успешно сделали аутентифицированные запросы с ресурсом, могут использовать те же учетные данные аутентификации для других ресурсов на том же сервере происхождения. Это позволяет другому ресурсу собирать учетные данные аутентификации для других ресурсов.

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

7. Благодарности

Эта спецификация берет на себя определение HTTP Authentication Framework, ранее определенное в RFC 2617 #. Мы благодарим Джона Фрэнкса, Филиппа М. Хэллам-Бейкера, Джеффри Л. Хостетлера, Скотта Д. Лоуренса, Пола Дж. Лича, Ари Луотонена и Лоуренса С. Стюарта за их работу над этой спецификацией. См. Раздел 6 [RFC2617 #] для дальнейших благодарностей.

См. Раздел 10 [RFC7230 #] для Благодарностей, связанных с этой версией документа.

8. Ссылки

8.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, June 2014.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, June 2014.

8.2. Информационные ссылки

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[OWASP] van der Stock, A., Ed., «A Guide to Building Secure Web Applications and Web Services», The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication», RFC 2617, June 1999.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

Приложение A. Изменения по сравнению с RFC 2616 и 2617

Структура для HTTP-аутентификации теперь определяется этим документом, а не RFC 2617.

Параметр «realm» больше не всегда требуется при вызовах; следовательно, ABNF разрешает вызовы без каких-либо параметров аутентификации. (Раздел 2)

Альтернатива «token68» спискам auth-param была добавлена для соответствия устаревшим схемам аутентификации, таким как «Basic». (Раздел 2)

Эта спецификация представляет Реестр Схемы Аутентификации наряду с соображениями относительно новых схем аутентификации. (Раздел 5.1)

Приложение B. Импортированный ABNF

Следующие основные правила включены посредством ссылки, как определено в Приложении B.1 [RFC5234 #]: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элементы управления), DIGIT (десятичное 0-9) , DQUOTE (двойная кавычка), HEXDIG (шестнадцатеричный 0-9 / A-F / a-f), LF (перевод строки), OCTET (любая 8-битная последовательность данных), SP (пробел) и VCHAR (любой видимый символ US-ASCII ).

Правила ниже определены в [RFC7230 #]:

BWS = <BWS, смотри [RFC7230 #], Раздел 3.2.3>
OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>
quoted-string = <quoted-string, смотри [RFC7230 #], Раздел 3.2.6>
token = <token, смотри [RFC7230 #], Раздел 3.2.6>

Приложение C. Собранный ABNF

В приведенной ниже ABNF правила списка расширены в соответствии с разделом 1.2 [RFC7230 #].

Authorization = credentials

BWS = <BWS, смотри [RFC7230 #], Раздел 3.2.3>

OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>

Proxy-Authenticate = *( «,» OWS ) challenge *( OWS «,» [ OWS challenge ] )
Proxy-Authorization = credentials

WWW-Authenticate = *( «,» OWS ) challenge *( OWS «,» [ OWS challenge ] )

auth-param = token BWS «=» BWS ( token / quoted-string )
auth-scheme = token

challenge = auth-scheme [ 1*SP ( token68 / [ ( «,» / auth-param ) *( OWS «,» [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( «,» / auth-param ) *( OWS «,» [ OWS auth-param ] ) ] ) ]

quoted-string = <quoted-string, смотри [RFC7230 #], Раздел 3.2.6>

token = <token, смотри [RFC7230 #], Раздел 3.2.6>
token68 = 1*( ALPHA / DIGIT / «-» / «.» / «_» / «~» / «+» / «/» ) *»=»

Индекс

4

401 Unauthorized (status code) 6
407 Proxy Authentication Required (status code) 6

A

Authorization header field 8

C

Canonical Root URI 5

G

Grammar

auth-param 4
auth-scheme 4
Authorization 8
challenge 4
credentials 5
Proxy-Authenticate 8
Proxy-Authorization 9
token68 4
WWW-Authenticate 7

P

Protection Space 5
Proxy-Authenticate header field 8
Proxy-Authorization header field 9

R

Realm 5

W

WWW-Authenticate header field 7

Адреса авторов

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/

Поделись записью