stringtranslate.com

Базовая аутентификация доступа

В контексте транзакции HTTP базовая аутентификация доступа — это метод, с помощью которого пользовательский агент HTTP (например, веб-браузер ) предоставляет имя пользователя и пароль при выполнении запроса. При базовой аутентификации HTTP запрос содержит поле заголовка в форме Authorization: Basic <credentials>, где <credentials>кодировка Base64 идентификатора и пароля, соединенных одним двоеточием :.

Первоначально он был реализован Ари Луотоненом в CERN в 1993 году [1] и определен в спецификации HTTP 1.0 в 1996 году. [2] Он указан в RFC  7617 от 2015 года, который устарел RFC  2617 от 1999 года.

Функции

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

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

Механизм BA не обеспечивает защиту конфиденциальности передаваемых учетных данных. Они просто кодируются с помощью Base64 при передаче и никаким образом не шифруются и не хэшируются . Поэтому базовая аутентификация обычно используется в сочетании с HTTPS для обеспечения конфиденциальности.

Поскольку поле BA должно отправляться в заголовке каждого HTTP-запроса, веб-браузеру необходимо кэшировать учетные данные в течение разумного периода времени, чтобы избежать постоянного запроса у пользователя имени пользователя и пароля. Политика кэширования различается в разных браузерах.

HTTP не предоставляет веб-серверу метода, позволяющего клиенту «выйти из системы» пользователя. Однако существует ряд способов очистки кэшированных учетных данных в некоторых веб-браузерах. Один из них — перенаправление пользователя на URL-адрес в том же домене с использованием намеренно неверных учетных данных. Однако такое поведение несовместимо между различными браузерами и версиями браузеров. [3] Microsoft Internet Explorer предлагает специальный метод JavaScript для очистки кэшированных учетных данных: [4]

< скрипт > документ . execCommand ( 'ClearAuthenticationCache' );</ script >

В современных браузерах кэшированные учетные данные для базовой аутентификации обычно удаляются при очистке истории посещений. Большинство браузеров позволяют пользователям специально удалять только учетные данные, хотя эту опцию может быть трудно найти, и обычно они очищают учетные данные для всех посещенных сайтов. [5] [6]

Подбор учетных данных активно не предотвращается и не обнаруживается (если не используется механизм на стороне сервера).

Протокол

Серверная часть

Когда сервер хочет, чтобы пользовательский агент аутентифицировал себя на сервере после получения неаутентифицированного запроса, он должен отправить ответ со строкой состояния HTTP 401 Unauthorized [7] и полем заголовка WWW-Authenticate . [8]

Поле заголовка WWW-Authenticate для базовой аутентификации строится следующим образом:

WWW-Authenticate: Basic realm="User Visible Realm"

Сервер может включить параметр charset из RFC  7617: [3]

WWW-Authenticate: Basic realm="User Visible Realm", charset="UTF-8"

Этот параметр указывает, что сервер ожидает, что клиент будет использовать UTF-8 для кодирования имени пользователя и пароля (см. ниже).

Сторона клиента

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

Поле заголовка авторизации строится следующим образом: [9]

  1. Имя пользователя и пароль объединяются одним двоеточием (:). Это означает, что само имя пользователя не может содержать двоеточие.
  2. Результирующая строка кодируется в последовательность октетов. Набор символов, используемый для этой кодировки, по умолчанию не указан, если он совместим с US-ASCII, но сервер может предложить использовать UTF-8, отправив параметр charset . [9]
  3. Результирующая строка кодируется с использованием варианта Base64 (+/ и с дополнением).
  4. Затем к закодированной строке добавляются метод авторизации и пробел (например, «Basic»).

Например, если браузер использует Aladdin в качестве имени пользователя и open sesame в качестве пароля, то значением поля будет кодировка Base64 Aladdin:open sesame или QWxhZGRpbjpvcGVuIHNlc2FtZQ== . Тогда поле заголовка авторизации будет выглядеть так:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Смотрите также

Ссылки и примечания

  1. ↑ Луотонен, Ари (10 сентября 2022 г.). «Анонсирование документации по авторизации доступа». [email protected] (список рассылки) . Проверено 7 февраля 2022 г.
  2. ^ «Протокол передачи гипертекста — HTTP/1.0» . www.w3.org . W3C. 19 февраля 1996 года . Проверено 7 февраля 2022 г.
  3. ^ ab «Есть ли браузер, эквивалентный ClearAuthenticationCache в IE?». Переполнение стека . Проверено 15 марта 2013 г.
  4. ^ «Идентификатор команды IDM_CLEARAUTHENTICATIONCACHE» . Майкрософт . Проверено 15 марта 2013 г.
  5. ^ «540516 — Удобство использования: разрешить пользователям очищать данные базовой аутентификации HTTP («Выход»)» . bugzilla.mozilla.org . Проверено 6 августа 2020 г. Очистить недавнюю историю->Активные входы (в деталях) используется для очистки аутентификации.
  6. ^ «Очистить данные просмотра — Компьютер — Справка Google Chrome» . support.google.com . Проверено 6 августа 2020 г. Данные, которые можно удалить[...]Пароли: Записи сохраненных вами паролей удаляются.
  7. ^ «RFC 1945, раздел 11. Аутентификация доступа» . IETF. Май 1996 г. с. 46 . Проверено 3 февраля 2017 г.
  8. ^ Филдинг, Рой Т .; Бернерс-Ли, Тим ; Хенрик, Фристик. «Протокол передачи гипертекста — HTTP/1.0». www.tools.ietf.org .
  9. ^ Аб Решке, Джулиан. «Базовая» схема HTTP-аутентификации. www.tools.ietf.org .

Внешние ссылки